OWASP top 5 issues presentation by Manish and Sumita

1. Manish Dusad (dusad@avaya.com)
Sumita Uday (suday@avaya.com)
All you wanted to know about
OWASP WEB TOP 10 !
Covering the first FIVE vulnerabilities

2. OWASP Web Top 5
• Injection
• Broken Authentication/Session Management
• Cross-Site scripting – XSS
• Insecure Direct Object Reference
• Security Misconfiguration

3. Injection
OWASP Definition:
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.

4. Injection

5. Injection
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
database
Server checks if the Password matches against the result of the
query
Query
Can be SQL like statements (mostly are)
Or, could be against an external system
LDAP
SSO

6. Firewall
Hardened OS
Web Server
App Server
Firewall
Databases
LegacySystems
WebServices
Directories
HumanResrcs
Billing
Custom Code
APPLICATION
ATTACK
NetworkLayerApplicationLayer
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
HTTP
request

SQL
query

DB Table


HTTP
response


"SELECT * FROM
accounts WHERE
acct=‘’ OR 1=1--
’"
1. Application presents a form to
the attacker
2. Attacker sends an attack in the
form data
3. Application forwards attack to
the database in a SQL query
Account Summary
Acct:5424-6066-2134-4334
Acct:4128-7574-3921-0192
Acct:5424-9383-2039-4029
Acct:4128-0004-1234-0293
4. Database runs query containing
attack and sends encrypted results
back to application
5. Application decrypts data as
normal and sends results to the
user
Account:
SKU:
Account:
SKU:

7. SQL Injection
• 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
testing.
• Can result in Data Stealing/Loss/Corruption

8. Recommendations
• 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 , … );
pstmt.setString( 1,
request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
– Stored Procedures

9. Recommendations
• Encode user input before passing to the interpreter
• Perform white list/black list input validation on all user
supplied input
– 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
flaw
• Use a vetted library or framework

10. Broken Authentication/Session Management
OWASP Definition:
Account credentials and session tokens are often not properly protected.
Attackers compromise passwords, keys, or authentication tokens to
assume other users’ identities.

11. Custom Code
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
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
a forum
www.boi.com?JSESSIONID=9FA1DB9EA...
4
Hacker checks referrer logs on www.hacker.com
and finds user’s JSESSIONID
5 Hacker uses JSESSIONID and
takes over victim’s account

12. • 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
logs, etc.
• Typical Impact
– User account compromised
– User session Hijacked

13. Recommendations
• 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();
session.invalidate();
 Implement Session Time-outs
 Change Session ID after successful login
 Set cookies as HTTP-Only and secure (on SSL)
AIC_SESSIONID=728CA9E50D86BA91384191F3793B064C; Path=/website;
HttpOnly

14. • Predictable Login Credential
• Credentials are not protected when stored
using hashing or encryption
• Password Strength
• Password Expiry
Broken Account and Session Management

15. 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.
15

16. Cross-Site Scripting (XSS)
• A quick View

17. Cross-Site Scripting (XSS)
• OWASP definition

18. 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
– Client XSS occurs when untrusted user supplied data is used to update the DOM with an unsafe JavaScript call.
– 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

19. Reflected Vs Stored

20. Recommendations
• 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
data into.
• consider auto-sanitization libraries like OWASP’s
AntiSamy
• Consider Content Security Policy (CSP) to defend
against XSS across your entire site.

21. Insecure Direct Object Reference
• OWASP definition

22. 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
Firebug:
If we jump over to the response tab, we start to see some really
interesting info:
{"d":{"__type":"Customer:#Web","Address":"3 NIBM
Road","CustomerID":3,"Email":“suday@avaya.com","FirstName":“Sumita","Pos
tcode":“411048","State":“MH",“City":“Pune"}}
Re-issue the
same request
but with a
different
customer ID

23. What made this possible?
• The fact that the customer’s ID was an integer;
auto-incrementing it is both logical and straight
forward.
• 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

24. Recommendations
• 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.

25. Security Misconfiguration
• OWASP definition

26. Recommendations
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
secure values
– 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