SPICON: Advanced Web Hacking (part 2)

Injection
Identifying output - looking for information that you send in that's going back out to you. (Finding injection in jump pages). Dynamic outputs, file parameters.
Identifying inputs - Referer, Cookies, Authentication headers (rare) - used to pull user from the auth headers to get state info, User-agent.
Input Validation
Blacklisting not so good - you don't know all permutations of bad characters. Whitelisting is better, but blacklisting is inevitable. Addslashes and magic quotes (php backslash-itis).
.NET validators - built-in controls
Common input validation mistakes - whitelist regex errors, blacklist regex failures (and shortfalls), top mistake - performing it in the client and not on the server.

Script Injection
XSS is just a subest of HTML Injection, which is just a subset of Response Injection. Find it by any time you see what you put in coming right back out.
Three ways to inject - by <script></script> tags, &script src="" /> tags, and injecting directly into existing tags. (He didn't mention injecting into existing script.)
DOM elements that are useful: window, location, document, form - reference to a really good PDF DOM Reference.

Validators
Validators are a fact of life. Assume they have errors, and work around them until you can find out what it will allow through. Validators will vary every time. A lot of time they're there for functional reasons, not security reasons.
Criteria:
1) Stripping, Escaping, or Rejecting?
2) What do they identify? Phrases? Words? ("select", or "union" or "union select")
3) Does the validator recognize encoded input?

Payloads
What can you do once you prove you can get through XSS.
- Write their login page to go to your site
- <img> tag with session token to your site
- XMLHttpRequest.

Types of attack:
Reflective attack - used for phishing
Persistent - stored for hitting lots of folks

XSS Vectors:
In SCRIPT tags
SCRIPT src
You can get script inside of JPEG (really early testing on that)

Great scenario (I love scenarios) of using persisted XSS to deploy a 0-day to

Remote Scripting / XSS Proxy
DOM trusts IFRAME as a child - use IFRAME to shovel your information off to your site. (He references this whitepaper from Apple).

Ajax
Stuff has been around forever, but it's starting to get unified enough to hang a name on it. Dangerous because it allows the browser to make background requests without user interaction.
Dangerous because it separates user interaction from actual action. The XMLHttpRequest is a full-featured HTTP client.
What can you do with it? Enumerate browsing history (CSS and DOM), Determine search terms, port scanning, XSRF (None of these really need XMLHttpRequest).

He went into a little bit of detail on XSRF, assuming XmlHttpRequest is somehow required for it. The best examples are change password.

Client-Side framing - including your site in a client frame.

SQL Injection
Very good opener - it's NOT a result of a lack of input validation - it's a result of parameter construction. It happens to be unmitigated by proper validation. These are the most pervasive type of webapp vulnerabilities (Editors note: Which is precisely why it's imperative for developers to know how to do data access properly).

Verbose vs. Blind - verbose gives you the results directly. Blind requires the "powers of deduction". Step 1 is USUALLY to try to get the db to return an error code directly.

Testing SQL Injection - quotes, bruted numerics.

Runtime error messages are your best friend here.

Once the vulnerability is identified, doesn't mean it's actually exploitable. Integers are the easiest to exploit (in his opinion) because of the lack of quotes to have to mess with.

He spent a great deal of time going through very specific examples, most of which syntactically or operationally require M$ SQL Server.

He spent (understandably) a very long time going over SQL Injection, and had some really good examples of dealing with blind. Obviously, if you find blind, a tool is super helpful. (And he didn't inject a shameless product plug. Somebody else did, however).

Overall, a much more in-depth afternoon, but still nothing "advanced".