OWASP Top 10
Vulnerabilities - 2013
- Vishrut Sharma
• OWASP stands for Open Web Application Security Project. An
online community that publishes methodologies, data on web
application vulnerabilities (detection and remediation
techniques), standards, tools and technologies.
Top 10 Vulnerabilities
• A1. Injection Vulnerabilities
• A2. Broken Authentication and Session Management
• A3. Cross Site Scripting (XSS)
• A4. Insecure Direct Object References
• A5. Security Misconfiguration
• A6. Sensitive Data Exposure
• A7. Missing Function Level Access Control
• A8. Cross Site Request Forgery (CSRF/XSRF)
• A9. Using Components with Known Vulnerabilities
• A10. Unvalidated Redirects and Forwards
A1. Injection Vulnerabilities
• An attacker may send untrusted data to an interpreter as part of a command or query tricking it into
executing such query and allows attacker to access data without proper authorization.
• Types: SQL injection, Blind SQL injection, OS Command injection, etc.
vulnerable SQL call:
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";
the attacker modifies the ‘id’ parameter value in browser to send: ' or '1'=‘1.
“ ‘ “ special character in SQL that specifies the beginning and end of string data.
A2. Broken Authentication and Session
• Caused by poorly configured custom code or misconfigured off-
• Credentials should always be protected: An authentication system
will need to pass some secret over the network. That secret
should either be encrypted or hashed with a salt and should not be
transmitted in clear-text.
• Session ID should be secured: Session ID should not be exposed in
the URL. It should be cryptographically random and should expire
once the user terminates the session.
A3. Cross Site Scripting (XSS)
• XSS is different from CSS (Cascading Style Sheets) which is a
mechanism to add style (font, color, spacing, etc.) to a web page.
• XSS is a type of injection attack that mostly affects HTML and Java
languages. XSS flaws occur whenever an application takes
untrusted data and sends it to a web browser without proper
validation or escaping. XSS allows attackers to execute scripts in
the victim’s browser which can hijack user sessions, deface web
sites, or redirect the user to malicious sites.
• Types: 1. Reflected; 2. Persistent or Stored; 3. DOM-based
A3.1 – Reflected XSS
• Client sends malicious input to a server and the server returns it back to the client. The client
executes the code in the context of the current user.
The following JSP code segment reads an employee ID, eid, from an HTTP request and displays it
to the user.
<% String eid = request.getParameter("eid"); %>
Employee ID: <%= eid %>
The code in this example operates correctly if eid contains only standard alphanumeric text. If
eid has a value that includes meta-characters or source code, then the code will be executed by
the web browser as it displays the HTTP response.
A3.2 – Persistent or Stored XSS
• Client sends malicious input to the server and the input is stored by the server. Later, the input is returned to another
client and the data is executed as code in the context of the current user.
An Input Box on a webpage to get email address from the user. The HTML code will look like below.
<input class="inputbox" type="text" name="email" size="40" value="email@example.com" />
Now, the attacker needs to find a way to inject code outside the <input> tag as below.
<input class="inputbox" type="text" name="email" size="40" value="firstname.lastname@example.org"><script>alert(document.cookie)</script>
This will get stored on the server and when another visits this page the browser will run the code and display cookie
information of the current user.
A3.3 – DOM-Based XSS
• Malicious input is never read from the server but instead sent by a malicious user
from some previous state in the browser. The malicious input, in this case, is not
attacking a vulnerability on the server but the vulnerable client-code.
document.write("Site is at: " + document.location.href + ".");
An attacker may append #<script>alert('xss')</script> to the affected page URL which
would, when executed, display the alert box. In this instance, the appended code
would not be sent to the server as everything after the # character is not treated as
part of the query by the browser but as a fragment. In this example, the code is
immediately executed and an alert of "xss" is displayed by the page.
A4. Insecure Direct Object References
• Occurs when a web application does not validate a client’s access
to a resource. Web applications frequently send a set of links that
have references to objects, such as database row, to their clients.
Consider this URL which references to account number of the user.
An attacker can change the value of acct and may open the account
details of another user.
A5. Security Misconfiguration
• Flaws that arise due to misconfiguration of products, protocols, or
• Missing Patches
• Misconfigured or disabled security features
• Default accounts
• Unnecessary/unused services, features, or ports
• Administrative backdoors
A6. Sensitive Data Exposure
• Sensitive data like password, credit card information, session ID,
etc. is either visible to users or transmitted in clear-text.
A site simply doesn’t use SSL for all authenticated pages. Attacker
simply monitors network traffic (like an open wireless network),
and steals the user’s session cookie. Attacker then replays this
cookie and hijacks the user’s session, accessing the user’s private
A7. Missing Function Level Access Control
• Application does not perform access control check when a user accesses a resource i.e. every
request the user makes is not verified for proper authorization. In such case, an attacker may
simply access any resource on the server.
The following URLs require authentication. Admin rights are also required for access to the
If an unauthenticated user can access either page, that’s a flaw. If an authenticated, non-admin,
user is allowed to access the admin_getappInfo page, this is also a flaw, and may lead the
attacker to more improperly protected admin pages.
A8. Cross Site Request Forgery
• A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and
any other automatically included authentication information, to a vulnerable web application. This allows the attacker to
force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
The application allows a user to submit a state changing request that does not include anything secret. For example:
So, the attacker constructs a request that will transfer money from the victim’s account to the attacker’s account, and then
embeds this attack in an image request or iframe stored on various sites under the attacker’s control:
<img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#" width="0" height="0" />
If the victim visits any of the attacker’s sites while already authenticated to example.com, these forged requests will
automatically include the user’s session info, authorizing the attacker’s request.
A9. Using Components with Known
• Components, such as libraries, frameworks, and other software
modules, almost always run with full privileges. If a vulnerable
component is exploited, such an attack can facilitate serious data
loss or server takeover.
Apache CXF Authentication Bypass – By failing to provide an identity
token, attackers could invoke any web service with full permission.
(Apache CXF is a services framework, not to be confused with the
Apache Application Server.)
A10. Unvalidated Redirects and Forwards
• Web applications frequently redirect and forward users to other pages
and websites, and use untrusted data to determine the destination
pages. Without proper validation, attackers can redirect victims to
phishing or malware sites, or use forwards to access unauthorized pages.
The application has a page called “redirect.jsp” which takes a single
parameter named “url”. The attacker crafts a malicious URL that redirects
users to a malicious site that performs phishing and installs malware.
• You will see, once you start scanning the applications and
analyzing the results, a mention of vulnerability called Blind SQL
Injection. Blind SQL Injection is a bit different than SQL Injection.
• SQL Injection: Occurs when an attacker injects malicious SQL
query in a web application which fetches the result from
underlying database and shows as output.
• Blind SQL Injection: Occurs when an attacker injects SQL query to
perform true or false operations on database and determines
output based on application response.
Comparison of SQLi and Blind SQLi
SQL Injection Blind SQL Injection
Attacker relies on error message returned
Attacker might not see an error message
It directly passes the query It asks true or false questions to the
Attacker is able to see the result Attacker is unable to see the result
Attacker can reconstruct the database
structure based on application response
Attacker cannot perform any operation on
Time-based Blind SQLi
• Works on the basis that true or false queries can be answered by
the amount of time a request takes to complete. For example, the
statement waitfor used with the delay argument causes SQL server
to pause for the specified period of time.
waitfor delay ‘0:0:5’
This will pause the query for 5 seconds.
Why Blind SQL Injection
This attack is often used when the web application is configured to show
generic error messages, but has not mitigated the code that is vulnerable
to SQL injection.
When an attacker exploits SQL injection, sometimes the web application
displays error messages from the database complaining that the SQL
Query's syntax is incorrect. Blind SQL injection is nearly identical to
normal SQL Injection, the only difference being the way the data is
retrieved from the database. When the database does not output data to
the web page, an attacker is forced to steal data by asking the database a
series of true or false questions. This makes exploiting the SQL Injection
vulnerability more difficult, but not impossible.