OWASP Attacks Part 2 - Exploitation of Authentication

Moved to New Site

Cross-Site Request Forgery (CSRF) aka One-Click attack
The goal of a CSRF is not to steal information directly, but to force a user into performing actions that they are unaware of.
A cornerstone premise for this attack is that a site/application that you are logged into will perform all actions as you since your credentials are already stored via cookie or session variables.
For example,
Say an attacker knows Dennis uses Bank of Canada's web site.
Say the attacker knows of a CSRF vulnerability on the BOC website that can be performed with URL manipulation, something like this:

www.bankofcanada.com/transfer.php?account=5555&amt=400

If Dennis is logged into his BOC account and visits this link, 400 of his hard earned loonies are transferred over to the owner of account number 5555.
How can we get Dennis to visit this link?
We could XSS a site that he regularly visits, or we could use the company email that allows HTML, something like

<a href="https://www.blogger.com/www.bankofcanada.com/transfer.php?account=5555&amt=400">Look at this stupid cat!</a>

Dennis' insatiable love of cats just cost him $400.
There are countless ways of getting a person to click on a link. People hate blue links.

You should check your site to ensure there is not functionality that can be initiated purely from the URL or from any GET commands.

To detect this vulnerability you can set up a proxy between a browser and the site and examine the requests being made and then try to inject those same requests when logged in as another user.

There are a lot of ways that a site can defend its user base from such attacks. The most simple is to enforce session time out for users that are logged in, this is by no means a catch all, but it will help.
The best defense is to implement a  Synchronizer Token Pattern.
A random token is generated and included in forms/procedures of a site that ensure that a request to that functionality came from the site itself and not from an outside link/script.

Session Hijacking
When you log into a web site or web application the server needs to keep track of who you are, it does this by creating a Session ID. A session ID is a long string of alpha-numerical characters that is unique to your session with the server.
A session hijacking attack occurs when it is possible for an attacker to successfully obtain your session id or guess a future session id.

A session id can be stolen from network sniffing, a man-in-the-middle attack, cookie stealing, or XSS.
Once stolen an attacker can use a site/application while masquerading as the victim.

To help prevent session hijacking be sure your site has an up to date certificate and supports use of HTTPS.
Use a long, random session id, do not use something predictable such as the user id.
Do not reuse session ids.
Encourage users to log off after they are finished and include session timeout functionality, this will help prevent hanging sessions.

OWASP Attacks Part 1 Abuse of Functionality

MOved to New Site

If you are getting into security you should be very familiar with OWASP (Open Web Application Security Project.) They provide a huge amount of information about securing and attacking web applications. This series will glaze over all the attacks listed on their site and serve as either notes or primer info.

Abuse of Functionality
This occurs when an attacker can use a specific feature in your web application to meet an effect that you did not intend.

Account name harvesting
Most sites include a form that can be submitted to request a new password to be emailed to you if you have forgotten your creds. The form is normally just an email address or a user name input box and a submit button.
After this form submission they site responds in one of two ways
1. 'No account associated with that email/username' or 'User is not found' type of message
2. 'Password sent, please check spam filter' or 'A link to update your password has been sent'

This is improper, no matter if a username/email has a valid account on your system your page should always respond that consistently.
If not, you run the risk of an attacker abusing the functionality and harvesting a list of valid user names/emails that take use of your services.

This might not seem like much, but you will want to implement it to help fight against data aggregation

Single User DoS
Most sites will implement a three strike rule when it comes to logging in; Enter the wrong creds three times and there will be a temporary lock on the account or it will send email to the user to reset their password.
This is a feature that is implemented for the point of protecting us from password guessing attacks, but if an attacker knows a user that he needs disabled for a few minutes, he may just submit three false log ins for that account and let the system block his access for you?

Path Traversal
The goal of a path traversal is to point the application to the disk unkown, outside of the web root and into other roots.
The most ubiquitous tool for this is ../
This is the symbol used to move up one directory level.
It is most commonly done through URI manipulation, but can also be done with cookie manipulation.
Take a look at the url below:

http://noparse.com/load.php?get=/var/www/html/get.php

We could alter it:

http://noparse.com/load.php?get=../../../../../../../etc/passwd

Now this is just to give you a taste of how this attack works, and by no means exhaustive list, you are just one google search away from that:

Pro Tip: A fun way to look for these is with google, search for "inurl:'some directory'"

Client Side
This cannot be said enough, know the difference between client side and server side. All too often developers do not have a holistic view of their web app. Any verification of data integrity or character escaping you do on in client side languages can be bypassed 100% with zero effort on the attacker's part.
Always verify data on the server side.
Burn that phrase into your brain.