OWASP Attacks Part 1 Abuse of Functionality

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:

We could alter it:
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.