Web Apps Security

© 2014 IBM Corporation2
● The code that we write is not safe !
● Learn by exemplifying
● Introduce developer to security APIs

Interesting facts
● Myth: We are secure because we have a firewall
– 75% of vulnerabilities are at web application layer
Gartner Group (2002 report)
– Basically network layer protection just denies access to
services
● Myth: I am safe because I‘m connected via HTTPS/SSL
– HTTPS will just ensure that no one intercepts the
information.
– A web page can include static resources or other content
from the same host via a non secure channel

Interesting facts
● NASA counted 5,408 security breaches where some access was
given or malicious software was installed. In 2011 alone
they had 47 attacks they described as ―advanced persistent
threats,‖ serious attacks by well-funded ―individuals or
nations.‖ Of those, 13 succeeded, and one attack based in
China gained complete access to Jet Propulsion Laboratory
(JPL) systems — read, write, delete, add and delete
users, modify logs, everything.
● Paul Marting ( NASA inspector general ) in a written testimony to US
government
● Visa, MasterCard, AmericanExpress & Discover Financial
Systems, were hit in March by a data-security breach when a
third-party service provider ( Global Payments Inc.)
discovered its systems were compromised
● www.reuters.com

Let’s start with OWASP Top 10

● Open web application security project ( www.owasp.org)
● not-for-profit worldwide charitable organization focused on
improving the security of application software.
● Users and adopters of APIs and standards: US Federal Trade
Commision,Citibank, PwC, HP, IBM Global Services, US Bureau of
Alcohol Tobacco and Firearms,etc.
● OWASP Top Ten 2013 ( the 10 most common security flaws found
in web applications in 2013 ):
● A1 : Injection
● A2 : Broken Authentication and Session Management
● A3 : Cross-Site Scripting (XSS)
● A4 : Insecure Direct Object References
● A5 : Security Misconfiguration
● A6 : Sensitive Data Exposure
● A7 : Insecure Cryptographic Storage
● A8 : Cross-Site Request Forgery (CSRF)
● A9 : Using component with known vulnerabilities
● A10: Un-validated Redirects and Forwards
OWASP Top Ten

A1 Injection
● Various forms of injection
● SQL Injection
● Xpath injection
● Command injection
● Path based injection
● LDAP injection
● Etc.

© 2014 IBM Corporation
Select user_information
from user_table
where username='’' or 1=1 -– 'and
password=’abc’
8 A1 Injection
Select user_information from user_table
where username=’input username’ and password=’input password’
Web Server Application Server
User Database
User
https
SQL injection

© 2014 IBM Corporation9 A1 Injection
Xpath injection
FindUserXPath becomes :
//Employee[UserName/text()='blah' or 1=1 or 'a'='a' And
Password/text()='blah']
User Database
User
https
FindUserXPath = "//Employee[UserName/text()='" + Request("Username")
+ "' And Password/text()='" + Request("Password") + "']";
<?xml version="1.0" encoding="utf-8"?>
<Employees>
<Employee ID="1">
<FirstName>Arnold</FirstName>
<LastName>Baker</LastName>
<UserName>ABaker</UserName>
<Password>SoSecret</Password>
<Type>Admin</Type>
</Employee>
<Employee ID="2">
<FirstName>Peter</FirstName>
<LastName>Pan</LastName>
<UserName>PPan</UserName>
<Password>NotTelling</Password>
<Type>User</Type>
</Employee>
</Employees>

© 2014 IBM Corporation10 A1 Injection
Command injection
User Database
User
https
$ ls -l .profile ; cat /etc/password
$ “ls -l” + request.getParameter(“file_name”)

Path based injection ( manipulation / traversal )
● Atacker gains access to system files by
manipulating a 'path/to/file.txt' supplied
as a parameter
● For plain files, one can browse through the
file system with directory style paths (
../../../../conf/tomcat-users.xml )
● demo

© 2014 IBM Corporation12 A3 Broken authentication and session management
A2 Broken Authentication and Session Management
Attacker uses leaks or flaws in the
authentication or session management functions
to impersonate users.
• e.g., exposed accounts, passwords, session IDs

© 2014 IBM Corporation13 A3 Broken authentication and session management
● Session ids should not be exposed in the URL (
http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJ
UN2JV?dest=Hawaii )
● They will get recorded in logs of servers, proxies and routers can be
easily distributed
● Session cookies must be manipulated only by http headers sent by the
server (HttpOnly flag)
● Sessions should timeout in accordance to application risk rating
● All navigation within that domain should be secure (https) because an
attacker can 'snif' the session id and steal the session.
● Setting 'secure' flag on session cookies is a must. This way
session cookie will not be sent on insecure channels ( e.g.
including static resources or embedding remote html )
● Session ids should change after a login attempt
● This prevents session fixation attacks when an attacker obtains (by some
other means) the value of the session id and if the target user has a
valid logged-in session on a server, the attacker is able to join the
session just by setting the session cookie
● demo
A2 Broken Authentication and Session Management

© 2014 IBM Corporation14 A2 Cross site scripting
A3 Cross site scripting
● Stored XSS
● Reflected XSS

Stored XSS attacks
● An input field which is not properly validated will insert script tags
besides the usual field value
● If the field is displayed literally in another part of the
application, it will result in the code within the script tags being
executed
User Database
User
https
User Database
User
https

Other flavors of XSS
● Reflected input
● Input from the user is echoed to the screen. (e.g.
error messages like 'input X is invalid' – in this
case X can contain XSS code and more then often can
be sent to a different user via an URL)
● Pretty much all tags are vulnerable to XSS:
● All tags contain event functions
(onmouseover,onkeyup, etc.) and they can be passed
in as input somewhere
● HTML attributes are also vulnerable
● E.g <frame>, <iframe> and <img> can have the src
attribute javascript injectable ( e.g <iframe
src=‖javascript:alert(1)‖/> will be executed by
most browsers )
● Even css style tags are vulnerable.
● demo

Other flavors of XSS
● And XSS attack vector list goes on:
● <BODY BACKGROUND="javascript:alert('XSS')">
● <LINK REL="stylesheet" HREF="javascript:alert('XSS');">
● <STYLE>@import'http://ha.ckers.org/xss.css';</STYLE>
● <META HTTP-EQUIV="Link"
Content="<http://ha.ckers.org/xss.css>; REL=stylesheet">
● <STYLE>.XSS{background-
image:url("javascript:alert('XSS')");}</STYLE><A
CLASS=XSS></A>
● Comprehensive list of vectors:
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

Dangerous use of eval
● This is usually done when behavior of page
needs to be controlled from the server.
● E.g show different alert() windows.
● eval() function is the most dangerous. Do not
put dynamic content in the eval() function.
● The reason for this is that validation of input
which goes between the brackets of the eval()
is hard to validate. You can basically write js
and have the browser interpret it using a
simple set of characters.
● In some cases js code can NOT be
escaped/commented ( OWASP directive ), so it is
really hard to defend against this attack.
● demo

© 2014 IBM Corporation19 A4: Insecure Direct Object References & A5 Cross site request forgery
A4: Insecure Direct Object References & CSRF
● Cross site request forgery (CSRF)
● Direct object references

© 2014 IBM Corporation20 A4: Insecure Direct Object References & A5 Cross site request forgery
Request forgery and weak access control
● Attacker will 'forge' request
parameters based on 'similarities'
between actions and navigation
● Easiest to forge will be ids which are
usually sequential integers
● Normally all actions within an
application should rely on
authenticated principal(user) and NOT
on supplied parameters
● demo

© 2014 IBM Corporation21 A7 Insuficient cryptographic storage & A9: Insufficient Transport Layer Protection
A7 Insecure cryptographic storage &
A9: Insufficient Transport Layer Protection

Insecure HTTP header authentication
● Http header authentication is nothing but a
Base64 encoding of 'username:password‗
● Make sure all HTTP authenticated traffic is
encrypted
GET /exchange/ HTTP/1.1
Host: webmail.xxxx.xx
Connection: keep-alive
Cache-Control: max-age=0
Authorization: Basic dTI5ODMyOTpteV9wYXNzd29yZA==
User-Agent: Mozilla/5.0 (Windows NT 5.1) .....
Accept:text/html,application/xhtml+xml,.....
.....
dTI5ODMyOTpteV9wYXNzd29yZA==
u298329:my_password

Encryption algorithm strength
Numar de
caractere
Algoritm incriptare Nr chei / secunda Alfabet Timp
5 Raw MD5 8754 a-z, A-Z 44 seconds
5 Raw MD 5 8754 a-z, A-Z, 0-9 1 minutes 46 seconds
5 Raw MD 5 8754 a-z, A-Z, 0-9, !@#$%^&*()_+= 4 minutes 53 seconds
5 Raw SHA-256 2600 a-z, A-Z 2 minutes 29 seconds
5 Raw SHA-256 2600 a-z, A-Z, 0-9 5 minutes 58 seconds
5 Raw SHA-256 2600 a-z, A-Z, 0-9, !@#$%^&*()_+= 16 minutes 28 seconds
6 Raw MD5 8754 a-z, A-Z 38 minutes 22 seconds
6 Raw MD 5 8754 a-z, A-Z, 0-9 1 hours 49 minutes 54 seconds
6 Raw MD 5 8754 a-z, A-Z, 0-9, !@#$%^&*()_+= 6 hours 11 minutes 46 seconds
6 Raw SHA-256 2600 a-z, A-Z 2 hours 9 minutes 13 seconds
6 Raw SHA-256 2600 a-z, A-Z, 0-9 6 hours 10 minutes 4 seconds
6 Raw SHA-256 2600 a-z, A-Z, 0-9, !@#$%^&*()_+= 20 hours 51 minutes 43 seconds
8 Raw MD5 8754 a-z, A-Z 72 days 1 hours 37 minutes
8 Raw MD 5 8754 a-z, A-Z, 0-9 293 days 9 hours 50 minutes
8 Raw MD 5 8754 a-z, A-Z, 0-9, !@#$%^&*()_+= 4 years 30 days 5 hours 57 minutes
8 Raw SHA-256 2600 a-z, A-Z 242 days 15 hours 29 minutes
8 Raw SHA-256 2600 a-z, A-Z, 0-9 2 years 257 days 9 hours 43 minutes
8 Raw SHA-256 2600 a-z, A-Z, 0-9, !@#$%^&*()_+=
13 years 272 days 15 hours 55 minutes

Password strength
Brute-forcing passwords
• '1234567890' can be cracked in 472 s
• 'plainpw' can be cracked in 420 s
• 'PlainPw' can be cracked in 1681 s
• 'Pl4inPw' can be cracked in 126 days
• 'P|4inPw' can be cracked in 21 years

Password strength
Be careful when using forward() and include()
• It‘s an internal mechanism which will bypass
standard AS authorization
• request.getRequestDispatcher(―protectedUrl‖)
• forward()
• include()
• demo

Mitigating security threats

● OWASP created the ESAPI in order to 'mitigate'
the top 10 risks. The API is available in
pretty much every language ( JEE,PHP,
.NET,Python, Ruby, etc.)
● It is basically a collection of classes (API) that
encapsulate the key security operations that an
application needs
● It has been designed to make it easy for programmers
to retrofit security into existing applications
● It is scalable at enterprise levels

● It addresses the following aspects:
– Authentication
– Access control
– Input validation
– Output encoding/escaping
– Cryptography
– Error handling and logging
– Communication security
– HTTP security
– Security configuration
– And many more…
OWASP ESAPI

© 2014 IBM Corporation30 Input and output validation
Mitigating XSS and Injection attacks
• Canonicalize input
• Convert encoded %3c%3e → <>
• Convert encoded <> → <>
• Validate input (at least for these characters <>;:”'()'&)
• Best practice is to throw away potentially harmful content.
Do not try to 'clean up' the content, because many cleanup
algorithms can be circumvented ( OWASP )
• e.g. some_string.replaceAll(“<script>”,””); attacker can just
pass in “<scr<script>ipt>” and the result will be <script>
• Attack vector can also be “< script >”
• Can very well be “ < ScRiPt >”
• Use a whitelist of characters instead of blacklist (
permitted vs unpermitted ). The blacklist can never be
comprehensive enough.
• Attacks can be extremely complex, so there is also a wide
range of characters that can pose threats

• It is designed to throw meaningfull exception if an attack is suspected
●IntrusionException in case a potential attack is detected ( harmfull
characters present)
● ValidationException in case an validation rules fail ( double encoding
present and an attack is suspected)
–For Http parameters
●ESAPI.validator().assertValidHTTPParameters(...)
–For file path based parameters
●ESAPI.validator().getValidDirectoryPath(..)
●ESAPI.validator().getValidFileName(..)
–For plain HTML input
●ESAPI.validator().getValidInput(..)
Use ESAPI Validator

● Contextually encode output
– For HTML ( e.g ESAPI HTML encoder )
● ESAPI.encoder().encodeForHTML(..)
– For tag attributes (e.g ESAPI HTML attribute
encoder )
● ESAPI.encoder().encodeForHTMLAttribute(..)
– For CSS ( e.g ESAPI CSS encoder )
● ESAPI.encoder().encodeForCSS(..)
– For Javascript ( e.g. ESAPI Javascript encoder)
● ESAPI.encoder().encodeForJavascript(..)
– For queries in LDAP Dbs:
– demo
● ESAPI.encoder().encodeForDN(...)
Use ESAPI encoder

Encoding of output example
● A developer can also encode output. Using the ESAPI.encoder() you
can generate safe HTML, Js, CSS,...
● Below we are encoding this string → <>"'%&.()[]@#//-+
– Encoding for HTML :
– <>"'%&.()[]&#x
40;#//-+
– Encoding for CSS :
– 3c 3e 22 27 25 26 2e 28 29 5b 5d 40 23 2f 2f
2d 2b
– Encoding for JS :
– x3Cx3Ex22x27x25x26.x28x29x5Bx5Dx40x23x2Fx2Fx
2Dx2B
– Encoding for html attribute :
– <>"'%&.()[]&#x
40;#//-+

● Keep things simple
● Use mature APIs/frameworks
● Don‘t give away info about the system
● 404 errors, exceptions, html comments
● Keep entire site under https
● Encode output contextually
● Validate input globally
● Keep sessionid safe ( httponly, secure )
● Change it after successful login
Checklist

Thank you !
by Victor Bucutea

Web Apps Security

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (15)

Similar to Web Apps Security

Similar to Web Apps Security (20)

Recently uploaded

Recently uploaded (20)

Web Apps Security

Editor's Notes