Source Code Assessment Strategies

Must be ideal thought day even though I'm doing billable work :-)

When reviewing source code, I find I use these three strategies / heuristics:

• Breadth-first, shallow depth
• Depth-first, based on information / judgment
• Hill-climbing, using general security categories as neighbors

Breadth-first is used to get a feel for the app. If something smells about the app, then a depth-first occurs at that area after the breadth-first search. Also, any business drivers or common application patterns are used to drive other depth-first searches. Once these are exhausted, any other security categories are chosen and followed, almost like a stochastic hill-climbing strategy. Usually by this time, project time is running out and documentation is occurring.

What do you use?

Probably Nothing Special: Blabbermouths on Twitter

Had a side thought that I'm sure someone has already thought of and implemented:

• Find an account on Twitter that requires authz to view his or her account
• From an authn'd but unauthz'd Twitter API client, do the following:
• Enumerate all the followers and following of this person (authn'd users can do this)
• Search favorited tweets from this user; store the blabbermouth
• Search conversations from this user; store the blabbermouth
• Search RT's / @mentions for this user; store the blabbermouth
• Use the gathered favorited and conversation data to reconstruct a timeline (tweet IDs are time stamps) of possible tweets
• Use the @mentions and RTs to match up the tweet to a possible timeline tweet

It's more that likely that one cannot construct a full timeline of some target's tweets. Also, matching up the RTs / @mentions is fraught with mismatching. But, one could start to see who blabs out all of the tweets and then unfollow that person. I'm sure my account would be unfollowed since I do the above with impunity :-) That is, Twitter is not meant for secrets.

XSSed By Gareth Heyes

I recently got an iPad to be extra douchey. I'm using it as a PDF and eBooks reader mostly and wanted to get a good RSS reader in the mix. While Google Reader isn't bad, and under the hood it output encodes the crap out of everything, I'm not a big fan of the interface. I looked around for some app-specific readers and came across Feeddler.

Feeddler can authenticate, via credentials (yuck) to one's Google account. (Note to self, create another google account just for RSS feeds. Note to others, my XSSed gmail account is only used for RSS and this blog.) Once authenticated, it grabs the Google feed settings and then parses it, displaying a similar outline to Google Reader.

I've been out of touch with my RSS feed lately and started going through the back issues. I flipped open The Spanner, an insightful feed authored by Gareth Heyes. Do not follow him on twitter, btw.  And, for the yanks in the group, a spanner is a wrench. The article, XSS Zones, ironically fired an XSS in Feeddler:

Got XSSed by @garethheyes and all I got was an alert(1)

 Here's the evil code:

<!– End XSS zone –><img src=1 onerror=alert(1)> and they have broken out of the

See that HTML-encoded img tag? Yeah... Dunno what's going on under the hood, but between Feeddler, Google Reader, and the article, Feeddler decided to execute that block and fire an alert. D'oh!! So, now anyone can XSS Feeddler via a properly encoded feed and have fun in the context of probably one's Google Reader account. Not funny :-)

Needless to say, I went back to Google Reader and quickly deleted Feeddler.