Plans for My Clojure Project

I've been learning clojure in my spare time and I think I'm at a point in my understanding of the language to produce something fun and useful. Well, not necessarily useful, but definitely fun! I like to specify my plans in great detail in order to organize my thoughts and decompose large problems into distinct and unrelated bits. Here's a sort of 'dump' of my mental DB from the last week of erudite Subway-meditation:

Because I'm an internet person with what I like to think is an exquisite sense of humor, I will be writing a easily-deployable server that can create memes for you from given templates. Potential features of the server itself are as follows:

  • Upload templates
  • List current templates
  • Create a top / bottom caption style meme from any template
  • Create a demotivational style meme from any template
  • Store files on either an S3 bucket, local folder or maybe Imgur (pending API research)
  • List images generated from each template

None of these features should be too difficult for someone new to Clojure. I expect the largest complications will come from interfacing with external APIs.

So far, I've neglected to discuss how users will interact with the server. This is actually the most interesting part of the project for me. I'm not very interested in re-hashing or anything like that. I'm interested in creating alternative interfaces that would fit better in my workflow. (Yes, my lulz workflow.)

Initially, there will be two ways to speak to this server:

  • HTTP (REST-like API)
  • Command-Line (Using single commands like meme --gen y-u-no "Take out the trash!" or running a sort of REPL that does this)

I spend pretty much all my time on the command line, if I can, so not having to open Photoshop or go to a pretty ugly and obnoxious website to provide 'quality entertainment' is nice!

My choice of front-ends to the server also afford me a great deal of flexibility. My primary design goal here is absolute separation of concerns between client and server. I've always felt like there are so many applications with very useful backends, but utterly crippling frontends. I can offer the simplest tools first, and use these tools as building-blocks for more complex interfaces. The HTTP interface means writing a client library, rebuilding or anything else will be simple and require no code changes to the backend.

This very strict separation, inspired heavily by the UNIX design principle of building complex tools out of modular pieces with a single concern is what I will be most proud to see enacted once this is over. I also have plans to build a version of Catan to run in the office to play asynchronously during a slow evening / turn-based throughout the day without having to deal with the setup / teardown of a board game when it's just not feasible. That's the subject of a later post, but I plan to re-apply the lessons learned here to that project.

That's all I've got for now, but I will be regularly blogging (Hopefully with code.) about my progress on this silly little project. I think I've got an interesting idea for a debugging tool for the image manip. library inspired by LightTable. Time to get started!

A Silly Trick I Learned During Stripe CTF

I recently participated in Stripe Capture the Flag and after completing six of the eight levels I learned a fair bit about browser security and a few server-side attacks. It was an extremely valuable experience not simply because I learned a few tricks, but because It renwed my awareness of security holes. Of the things I've learned, the following Javascript 'trick' was probably the most amusing / my favorite.

Level 6 of the challenge takes place on a server that hosts a sort of social network. Users can log in and post things to a public 'Wall'. There is another user on the system that logs in to check on recent posts approximately once every five minutes. There is also a page on the application which will show the current user's password in plain text (!).

My first approach was to use XSS to ebmed a harvesting script in a post. The script would make an XHR request to the page that shows the current user's password and post it back to the wall automatically, leaving a landmine for the other user. Getting anything executable on the page involved some breaking parsing on the JSON string embedded in the page that showed the recent posts, and a single tag in any message body will do that. At that point, the various client-side encoding / filtering that happens when a new message is posted cannot run.

I thought I was home-free, but it turns out the server rejects any posts with a single or double quote in the body or title. Writing Javascript that will request a URL and parse a bit of the DOM without ant quotes is...hard. Loading a script from a 3rd party server to do this work wouldn't work because of the Same-Origin Policy. These scripts wouldn't have access to the current user's cookies when requesting the password page.

I had to figure out a way to embed the executable script in a post without any quotes...after a bit of brain wracking over encoding quotes, I realized the Javascript String prototype has a useful method called 'fromCharCode' that will take an arbitrary number of unicode character codes and produce a string that is the concatenation of their ASCII representations. This was my way in. So I converted all my code to a string of the form "eval(String.fromCharCode(....))" that sucessfully posted and harvested the victim's password. The fact that this is possible and that the challenge called for it was kind of awesome, so here's the ridiculously simple helper function that got me to Level 7.

Stripe really created something great with this competition. I feel much more confident in my understanding of the subtle ways in which browsers protect users from malicious content and that my own code is (hopefully!) better protected than some of these challenge's sites! ;)

Thanks, Stripe. It was fun.