Attacking Web Applications
Attacking Web Applications
Join the DZone community and get the full member experience.Join For Free
My first breakout session at the SELA Developer Practice covered the most common attacks against web applications and how to defend against these attacks. When planning this talk, I knew 60 minutes are hardly enough to cover all common vulnerabilities -- especially if I wanted to show any demos -- so I decided to focus on the three most prevalent vulnerability types, according to the OWASP Top 10:
- Injection (command injection and SQL injection)
- Broken authentication or session management
- Cross-site scripting (and CSRF as a bonus)
I've demonstrated these common vulnerabilities in a series of demos using toy applications -- DVWA and Google Gruyere. Unfortunately, with very little effort, I could find real targets to exploit by doing a simple Google search. Knowledge is power, and power must be wielded wisely...
OS Command Injection
I used DVWA (Damn Vulnerable Web Application) to demonstrate OS command injection. DVWA ships with a helpful "free ping tool" that lets you input an IP address and run an OS 'ping' command on your behalf. When given the following input, DVWA hangs and waits for connections on port 13371 and runs whatever commands you type through that connection:
127.0.0.1;mkfifo /tmp/pipe;sh /tmp/pipe | nc -l 13371 > /tmp/pipe
I used Google Gruyere for this demo -- specifically, the cookie manipulation vulnerability. You can read more about it on the official Gruyere documentation.
Insecure Password Storage
I demonstrated -- using the LinkedIn hash leak -- that storing weakly hashed passwords is not enough. Specifically, LinkedIn users chose horrible passwords like "password" and "iloveyou", and a plain SHA-1 of this kind of password is not going to withstand even the free online rainbow tables, like OnlineHashCrack.com. We then discussed salting and hashing passwords, and using slower hash functions like bcrypt (at the risk of DOS'ing your service when multiple concurrent login requests are issued).
XSS and CSRF
Again, I used Google Gruyere for this demo -- it allows multiple opportunities for persistent and temporary XSS. For example, when the URL is invalid, Gruyere reflects that URL into the error page without escaping, which allows embedding scripts in the URL which Gruyere then happily plays back to the user. For more types of XSS and CSRF vulnerabilities in Gruyere, see the official docs.
Finally, I talked about how it's easy to find open admin consoles that allow anyone on the Internet to pry deep into the bowels of your web server and even obtain logs and traces that contain sensitive information, such as authentication cookies. As an example, try this Google search for ELMAH pages that contain an ASP.NET authentication cookie.
One Advisory To Rule Them All
I concluded the talk by mentioning the recent vulnerability advisory for a certain class of DLink routers. This single advisory contains XSS and CSRF issues, information disclosure holes, insecure password storage problems, and OS command injection opportunities.
Thank you for coming to the talk, and I look forward to meeting you during the rest of the conference or at the next SDP!
Published at DZone with permission of Sasha Goldshtein , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.