SPICON: Advanced Web Hacking (part 1)

Most of this is going to be old information, so I'll mostly go over the highlights. I'll fill in gaps in later posts.

Matt Fisher SPI Dynamics

Matt is going to start off with demonstrating for the security folks how the code looks. It's easy to teach security to a coder, but it's more difficult to teach the security folks the code, but that's the differentiator.

He's going over <form> tags and the elements that can go in there. He asked if anybody was aware that "hidden" tags are not so hidden, and that the values in checkboxes, radios, and selects could be manipulated - to gauge experience level - not news to anybody. Unfortunately, he just asked if he was going too slow, only one thought he was going too slow.

He keeps referring to messages as "packets" - so the HTTP Request "packet" and HTTP Response "packet". That's going to annoy me.

He doesn't know much about .NET, and nothing about Java on the web side. All of his examples will be old-school ASP. I'll forgive him there, as the concepts still work precisely the same.

Difference between GET and POST.

Plain-text application protocols (like HTTP, SMTP, NNTP, blah, blah, blah)

Script files and how they're included. (Interesting side note - at one point he said "script is dangerous" and then moved on. Kinda' like "malicous characters, I guess".

Side story of using WI to break into a site by finding a backup file, which happened to be the authentication script, which had db connection strings, etc., etc.

Discusses, in particular, DSN information kept in the script code. If you're able to get the code, you've got the credentials to the db (which 99% of the time are too privileged for the needs of the app).

Morals of tha story

• Configure safeguards so that the web server processes the files (.bak, .inc, .old, etc.)
• Don't store those types of files in web-accessible folders (.htaccess)
• Actually use a proper development lifecycle where those things are properly culled out prior to a push to production

Browsers deal with a lot of stuff on their own.

HTTP overview. Methods. WebDAV methods == BAD.

Directory browsing and how to turn it off (at least in IIS).

Fingerprinting the webserver:

• Header
• Footers (!)
• Extensions

Cookies and their attributes. HttpOnly is skipped (no surprise because only IE supports it, and a lot of the HTTP Request poop has been fixed.)

Matt spent a few minutes looking at HTTP Request/Response pairs to see what kind of interesting information can be gleaned from them.

Authentication
Client-side password hashing - easily improperly implemented - just hash the password vulnerable to replay attacks (proper hashing later).
HTTP authenticaiton v. Form-based authentication.
Discussed salting vs. nonce, and how salting is used to avoid rainbow attacks, but didn't really mention that the salt is kept in the db.
Matt did a good job of explaining a nonce-hashed password. Didn't mention that the web server already has to have session state, though.

Session ID Security
Session to be used to save state, for authorization, for form auth, and for providing short-term memory.

Matt presented an interesting analogy of using your ID to get into a building, then they give you a guest badge - you're not showing your ID anymore, just the guest badge, which is a representation of the ID. (Not new information, but a good analogy for beginners.)

Defending against Session-ID analysis - he kept mentioning using GUID's - just use the system one! Didn't mention .NET's hard timeout on sessions (not the click delay, but a hard duration).

Encryption Boundaries:
http://www.webappsec.org/rss/websecurity.rss


Unauthenticated/Non-SSL
Anonymous pages
Go-to Login Page

Authenticated/SSL
Submit Credentials
App sets new session ID
Sensitive information exchange
Logoff

Audit Points
Make sure new session ID once user logs in.
Properly abandond session when the user logs off.

State
Keep track of who is who
Required for form-based authentication
Access Control
Required for providing server-side memory

Stateful not necessarily == sensitive
Not only do you need to protect access to anything sensitive, but also to anything that gives access to that sensitive info (i.e., CC# on server side - you must protect the session ID as well).

Next talked about sensitive information in GET vs. POST. GET, shows up in history, logs, logs, logs, logs.

Then lunch. Yum - AND I sat next to Jason Schmitt who does the Developer Security blog on the SPI site. He didn't have any good excuses for the lack of new content in his blog.