OWASP Top 10 Security Risks (2013)

Steven Jimenez
Nov 6, 2016 · 7 min read

I am interested in learning more about security within applications. As a developer I have been focused on being able to build applications for users that don’t have the intentions on doing harm or stealing my data. Developers focus on making the applications simple and efficient. This way of thinking sets us up for failures within the realm of security. If we don’t ask questions like, “how vulnerable does this new feature make our application”, or “how can someone attack my database from this feature” then we are leaving possible open doors for attackers to find. In order to avoid creating vulnerabilities we should understand what risks to look for.

A1 Injection

An injection attack occurs when an attacker sends text based data to the application and eventually gets interpreted in the database layer. A successful injection attack will reveal database schemas or data to the attacker. TeamBerserk, a group of attackers in 2013 were able to steal $100k of money from users, and it all started with a injection attack.

Injection flaws can be easily found within code. Some places to review would be areas of code where that user input is handled and where this data is included in any database query executions.

A2 Broken Authentication and Session Management

Attackers will take advantage of weak authentication and session management to steal accounts or use other accounts for malicious actions. Authentication and session management is used to correctly identify the user making the request. Some authentication and session management functionality includes reset password, forgot username/password, remember me, and forget password

An example of a good session management are some bank sites such as Chase. Their site will sign a user out after sensing there hasn’t been any activity after a certain amount of minutes. Other sites also ask for re-authentication for changes in profiles or sensitive data. This helps keep activity safe from unexpected users or unwanted phony users.

A3 Cross-Site Scripting (XSS)

XSS attacks happen when client side scripts are embedded onto pages that may be visited by other users. This is mostly used to by pass access controls and to abide by the same origin request policy.

An example of this type of attack is when a site renders data (given by the user) and the data is not properly validated or sanitized. In this case let’s say the application renders a url. The attacker can replace variables or add on executable scripts to the url in order to steal user sessions or cookies. A great way to prevent theses attacks is to use sanitation libraries to escape and clean data before and after they are rendered onto the html content.

A4 Insecure Direct Object References

Some applications have some restricted access depending on the different account types they have available for a user. Take for example an admin user vs a basic user. An admin may have the access to see all of the current basic users in the system along with some personal data that was given by the user. The application would want to keep any admin related pages for admin access only. Giving a basic user the ability to view an admin web view would be an authentication flaw.

Let’s take the same application and assume that it is not as secure as we thought it was. Under “My Profile” I can see some of my sensitive information, and I decide to change the url from /my_profile?user=123 to /my_profile?user=124. If the application has insecure direct object references, or does not handle request authentication correctly then I am able to act as another user and have access to other sensitive data.

A5 Security Misconfiguration

Different components of applications may have 3rd party add ons. These components at times come with default passwords and usernames. Attackers may use the knowledge of these components to try and hack into the application and steal valuable information. Other security misconfiguration is showing stack traces when an error occurs in your application. Stack traces will reveal what your application does when a specific request is made.

In order to avoid these vulnerabilities, it would be a good idea to update your application components, libraries, remove default username and passwords, and keep environment keys secret.

A6 Sensitive Data Exposure

This problems happens when an application does not apply strong encryption to secure data such as passwords, financial information, private health data, and session cookies.

Things to think about when securing data:

  • Is data privately transferred between the browser and the server? Is the application using SSL (Secure Sockets Layer)
  • Making sure data is not stored in plain text within the database. Instead the passwords should be encrypted and hashed.
  • Does the application use any encryption keys to decrypt sensitive? Are encryption keys ever regenerated or salted?

A7 Missing Functional Level Access Control

Failure to ensure that all possible user requests or views have the appropriate access control authorization will expose data or functionality to the wrong users. At times applications will miss some needed authentication checks and display the unauthorized functionality within the site.

If you ever built a content management site for someone you may know that there is an admin view that can be accessed by navigating to site.com/admin. This usually always prompts users to enter a username and password to access the admin view or dashboard. An example of missing functional level access control is if a basic user navigates to site.com/admin and is automatically granted access to this specific part of the site.

A8 Cross Site Request Forgery (CSRF)

This attack happens when malicious requests are made within a user’s browser to gain authenticated data or to perform authenticated actions through a user. If the user is authenticated, the attacks will succeed.

The best way to defend against these attacks would be to check the request headers to identify more information about where the request is coming from or if it contains the correct authorization. However keep in mind that the attacker can have full control of what is in the header and request.

Another good defense would be to check the CSRF token. This token usually is found hidden within a form and sent with the request when submitted. The server can then decide what actions to take after validating the token.

A9 Using Components with Known Vulnerabilities

As developers, we don’t want to reinvent the wheel so we turn to libraries. Libraries help increase the speed of developing features and applications. However the issue with libraries is that they are created by other developers. Which means there may have been zero consideration in security and possible vulnerabilities when creating theses libraries.

It is important to keep up to date with the latest versions of the libraries that you are using. Joining mailing lists or following blogs on tech related announcements will keep you aware of possible vulnerabilities that you may have inherited.

MongoDB is a pretty cool non-relational database library that is commonly used. Have you thought about the vulnerabilities that exist?

A10 Unvalidated Redirects and Forwards

If your application has redirects or forwards that is determined or built using parameter values you may be vulnerable to these attacks. Attackers can disguise a malicious redirect and direct users into sites that will initiate a download or a phishing attack.

The general advise is to avoid redirects and forwards. If needed then make sure the application does not include parameters. However if you need to include the parameters then the application needs to include special validation for the parameter values given and some user authentication to keep things secure.

GitHub Security

Now if all this information is not new to you, and you believe that you are a master of finding vulnerabilities within applications, check out GitHub Security and become a bug bounty hunter!

Comments, Questions or Concerns

If you see anything that I can improve on please feel free to highlight or comment. Any help would be great.

  • See something that isn’t correct?
  • Did I fail to explain a vulnerability?
  • Is there more that I should add on a topic?

References

Steven Jimenez

Written by

New Yorker — Engineer — Music Head — Latino

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade