I was the 546th person to complete Stripe's web security CTF and again had a ton of fun applying my theoretical knowledge of web security issues to the (semi-)real world. As I went through the levels I thought about what red flags jumped out at me (or should have) that I could apply to future code reviews:
| Level | Issue | Code Review Red Flags |
|---|---|---|
| 0 | Simple SQL injection | No encoding when constructing SQL command strings. Constructing SQL command strings instead of SQL API |
| 1 | extract($_GET); | No input validation. |
| 2 | Arbitrary PHP execution | No input validation. Allow file uploads. File permissions modification. |
| 3 | Advanced SQL injection | Constructing SQL command strings instead of SQL API. |
| 4 | HTML injection, XSS and CSRF | No encoding when constructing HTML. No CSRF counter measures. Passwords stored in plain text. Password displayed on site. |
| 5 | Pingback server doesn't need to opt-in | n/a - By design protocol issue. |
| 6 | Script injection and XSS | No encoding while constructing script. Deny list (of dangerous characters). Passwords stored in plain text. Password displayed on site. |
| 7 | Length extension attack | Custom crypto code. Constructing SQL command string instead of SQL API. |
| 8 | Side channel attack | Password handling code. Timing attack mitigation too clever. |
More about each level in the future.
Stripe is running a web security capture the flag - a series of increasingly difficult web security exploit challenges. I've finished it and had a lot of fun. Working on a web browser I knew the theory of these various web based attacks, but this was my first chance to put theory into practice with:
Here's a blog post on the CTF behind the scenes setup which has many impressive features including phantom users that can be XSS/CSRF'ed.
I'll have another post on my difficulties and answers for the CTF levels after the contest is over on Wed, but if you're looking for hints, try out the CTF chatroom or the level specific CTF chatroom.
Brief history and scope of the Internet Archive.
This page is a high-level overview of the project and provides guidence on how to implement the intents in your applications without the need for the you to understand the entire spec.
Javascript tool says if a photo is shopped. It can tell by looking at the pixels. Seriously. Links to cool presentation on the theory behind the algorithm behind the tool: http://www.wired.com/images_blogs/threatlevel/files/bh-usa-07-krawetz.pdf
As a professional URI aficionado I deal with various levels of ignorance on URI percent-encoding (aka URI encoding, or URL escaping).
Getting into the more subtle levels of URI percent-encoding ignorance, folks try to apply their knowledge of percent-encoding to URIs as a whole producing the concepts escaped URIs and unescaped URIs. However there are no such things - URIs themselves aren't percent-encoded or decoded but rather contain characters that are percent-encoded or decoded. Applying percent-encoding or decoding to a URI as a whole produces a new and non-equivalent URI.
Instead of lingering on the incorrect concepts we'll just cover the correct ones: there's raw unencoded data, non-normal form URIs and normal form URIs. For example:
In the above (A) is not an 'encoded URI' but rather a non-normal form URI. The characters of 'the' and 'path' are percent-encoded but as unreserved characters specific in the RFC should not be encoded. In the normal form of the URI (B) the characters are decoded. But (B) is not a 'decoded URI' -- it still has an encoded '?' in it because that's a reserved character which by the RFC holds different meaning when appearing decoded versus encoded. Specifically in this case, it appears encoded which means it is data -- a literal '?' that appears as part of the path segment. This is as opposed to the decoded '?' that appears in the URI which is not part of the path but rather the delimiter to the query.
Usually when developers talk about decoding the URI what they really want is the raw data from the URI. The raw decoded data is (C) above. The only thing to note beyond what's covered already is that to obtain the decoded data one must parse the URI before percent decoding all percent-encoded octets.
Of course the exception here is when a URI is the raw data. In this case you must percent-encode the URI to have it appear in another URI. More on percent-encoding while constructing URIs later.
As a professional URI aficionado I deal with various levels of ignorance on URI percent-encoding (aka URI encoding, or URL escaping).
Worse than the lame blog comments hating on percent-encoding is the shipping code which can do actual damage. In one very large project I won't name, I've fixed code that decodes all percent-encoded octets in a URI in order to get rid of pesky percents before calling ShellExecute. An unnamed developer with similar intent but clearly much craftier did the same thing in a loop until the string's length stopped changing. As it turns out percent-encoding serves a purpose and can't just be removed arbitrarily.
Percent-encoding exists so that one can represent data in a URI that would otherwise not be allowed or would be interpretted as a delimiter instead of data. For example, the space character (U+0020) is not allowed in a URI and so must be percent-encoded in order to appear in a URI:
http://example.com/the%20path/
http://example.com/the path/
For an additional example, the question mark delimits the path from the query. If one wanted the question mark to appear as part of the path rather than delimit the path from the query, it must be percent-encoded:
http://example.com/foo%3Fbar
http://example.com/foo?bar
/foo" from the query "bar". And in the first, the querstion mark is percent-encoded and so
the path is "/foo%3Fbar".
As a professional URI aficionado I deal with various levels of ignorance on URI percent-encoding (aka URI encoding, or URL escaping). The basest ignorance is with respect to the mere existence of percent-encoding. Percents in URIs are special: they always represent the start of a percent-encoded octet. That is to say, a percent is always followed by two hex digits that represents a value between 0 and 255 and doesn't show up in a URI otherwise.
The IPv6 textual syntax for scoped addresses uses the '%' to delimit the zone ID from the rest of the address. When it came time to define how to represent scoped IPv6 addresses in URIs there were two camps: Folks who wanted to use the IPv6 format as is in the URI, and those who wanted to encode or replace the '%' with a different character. The resulting thread was more lively than what shows up on the IETF URI discussion mailing list. Ultimately we went with a percent-encoded '%' which means the percent maintains its special status and singular purpose.
“The syntax for allowed Top-Level Domain (TLD) labels in the Domain Name System (DNS) is not clearly applicable to the encoding of Internationalised Domain Names (IDNs) as TLDs. This document provides a concise specification of TLD label syntax based on existing syntax documentation, extended minimally to accommodate IDNs.” Still irritated about arbitrary TLDs.
The New Super Mario Bros. Wii is a great game. Its the fun of old school Mario with the addition of great graphics and the kind of multiplayer I've wanted for Mario since playing the original as a child: its got up to four player simultaneous cooperative multiplayer. I recommend it to anyone who has enjoyed Mario in the past. Watch this amazing video of level 1-3 you can unlock in the game.
As noted elsewhere, multiple players attempting to navigate platforms, grab power ups, and throw turtle shells creates new challenges but along with that there's new ways to be incredibly cheap.
Some rights reserved