Manish Dusad (email@example.com)
Sumita Uday (firstname.lastname@example.org)
All you wanted to know about
OWASP WEB TOP 10 !
Covering the first FIVE vulnerabilities
OWASP Web Top 5
• Broken Authentication/Session Management
• Cross-Site scripting – XSS
• Insecure Direct Object Reference
• Security Misconfiguration
Injection flaws, particularly SQL injection, are common in web applications.
Injection occurs when user-supplied data is sent to an interpreter as part of a
command or query. The attacker’s hostile data tricks the interpreter into executing
unintended commands or changing data.
What happens when the Login button is clicked?
User name & Password is sent to the server
Server does a lookup of the username/password against some
Server checks if the Password matches against the result of the
Can be SQL like statements (mostly are)
Or, could be against an external system
"SELECT * FROM
acct=‘’ OR 1=1--
1. Application presents a form to
2. Attacker sends an attack in the
3. Application forwards attack to
the database in a SQL query
4. Database runs query containing
attack and sends encrypted results
back to application
5. Application decrypts data as
normal and sends results to the
• Untrusted Data is sent to an interpreter as
part of a command or query.
• Other Database specific constructs can also be
passed to determine the DBMS used.
• Very prevalent, especially in Legacy Code.
• Easier to detect using Code Inspection, than
• Can result in Data Stealing/Loss/Corruption
• Use an interface that supports ‘bind variables’ – they allow
the interpreter to distinguish between ‘code’ and ‘data’
– Prepared Statements
String query = "SELECT * FROM accounts WHERE
account = ?";
PreparedStatement pstmt =
connection.prepareStatement(query , … );
ResultSet results = pstmt.executeQuery( );
– Stored Procedures
• Encode user input before passing to the interpreter
• Perform white list/black list input validation on all user
– create, alter, drop, rename, select,
insert, update, delete, grant, revoke,
@@version, exec, union, waitfor, order
by, case when, utl_, winhttp
• Minimize Database privileges to reduce impact of a
• Use a vetted library or framework
Broken Authentication/Session Management
Account credentials and session tokens are often not properly protected.
Attackers compromise passwords, keys, or authentication tokens to
assume other users’ identities.
1 User sends credentials
2Site uses URL rewriting
(i.e., put session in URL)
3 User clicks on a link to http://www.hacker.com in
Hacker checks referrer logs on www.hacker.com
and finds user’s JSESSIONID
5 Hacker uses JSESSIONID and
takes over victim’s account
• HTTP is a stateless protocol
– Credentials are have to go with every request
– Should use SSL for everything requiring authentication
• Session Management Flaws
– Session ID is used to track state, as HTTP doesn’t – just as
good as credentials to an attacker
– Session ID is typically exposed on the network, in browser
• Typical Impact
– User account compromised
– User session Hijacked
• Authentication should be simple, centralized and standardized
• Use the standard session ID provided by the container
– Change the name to avoid ‘obviousness’
• Make sure that SSL protects both, credentials as well as session ID
• Verify that logoff actually destroys the session
Session session = request.getSession();
Implement Session Time-outs
Change Session ID after successful login
Set cookies as HTTP-Only and secure (on SSL)
• Predictable Login Credential
• Credentials are not protected when stored
using hashing or encryption
• Password Strength
• Password Expiry
Broken Account and Session Management
Broken Account and Session Management: Protection
Password Storage - never store passwords in plain text. Passwords
should always be stored in either hashed (preferred) or encrypted form.
Protecting Credentials in Transit - to prevent "man-in-the-middle"
attacks the entire authenticated session / transaction should be
encrypted SSLv3 or TLSv1
Man-in-the-middle attacks - are still possible with SSL if users disable
or ignore warnings about invalid SSL certificates.
Replay attacks - Transformations such as hashing on the client side
provide little protection as the hashed version can simply be intercepted
and retransmitted so that the actual plain text password is not needed.
Types of XSS
• Server XSS
– Server XSS occurs when untrusted user supplied data is included in an HTML response generated by the server.
– The source of this data could be from the request, or from a stored location.
– The entire vulnerability is in server- side code, and the browser is simply rendering the response and executing any
valid script embedded in it.
• Client XSS
– The ultimate source of the data could have been from a request, or
from a stored location on the client or the server.
• Stored XSS Attacks
– Stored attacks are those where the injected script is permanently stored
on the target servers, such as in a database, in a message forum, visitor log,
comment field, etc.
• Reflected XSS Attacks
– Reflected attacks are those where the injected script is reflected off the
web server, such as in an error message, search result, or any other response
that includes some or all of the input sent to the server as part of the request
• All input must be validated against a positive or
“whitelist” of acceptable value ranges.
• You MUST use the escape syntax for the part of
the HTML document you're putting untrusted
• consider auto-sanitization libraries like OWASP’s
• Consider Content Security Policy (CSP) to defend
against XSS across your entire site.
Insecure Direct Object Reference
• OWASP definition
Insecure direct object references
After clicking the button, the
customer details are returned
and written to the page
Hitting the button exposes the following information in
If we jump over to the response tab, we start to see some really
but with a
What made this possible?
• The fact that the customer’s ID was an integer;
auto-incrementing it is both logical and straight
• Obviously the problem here was unauthorized
access and the solution is to add some controls
around who can access the service
– Establish an identity, validate access rights then run
the service otherwise bail them out.
– validating the user’s right access the customer
data before anything is returned by the service
• Using an indirect reference map
– An indirect reference map is simply a substitution of the internal reference with an
alternate ID which can be safely exposed externally.
• Check Access
– Each use of a direct object reference from an untrusted source must include an access
control check to ensure the user is authorized for the requested object.
Positive step forward for this vulnerability :
– Develop a repeatable process to reduce the surface of vulnerability
– Disable default accounts and change passwords
– Keep your frameworks up to date
– Develop a strong application architecture that effectively isolates components
and encrypts data which is especially important with sensitive data.
– Disable any unnecessary files or features
– Ensure security settings in development frameworks and libraries are set to
– Run tools (i.e. automated scanners) and perform regular audits to identify holes
in the security configuration
– Customize your error messages
– Get those traces under control
– Disable debugging
– Encrypt sensitive configuration data
– Apply the principle of least privilege to your database/others user accounts