Deconstructing website attacks - Eric Vanderburg

Deconstructing website attacks
© 2015 Property of JurInnov Ltd. All Rights Reserved
Eric A. Vanderburg, MBA, CISSP
Director, Information Systems and Security
Computer Forensic and Investigation Services

© 2015 Property of JurInnov Ltd. All Rights Reserved© 2015 Property of JurInnov Ltd. All Rights Reserved
The nature of website attacks
• Current state
• Attacks
– Injection attacks
– Cross Site Scripting (XSS)
– Session Management attacks
– Object reference attacks
2

Threats
Impacts
Threat and Impact

Current state
 Average breach costs $214 per record
 Average organizational cost $7.2 million per
incident
 Risk and compliance budgets expected to
increase by 21%
4

$548 million
The US government
is increasing cyber
security R&D by 35%
to $548 million next
year
More organized
outside attacks
Facts and Figures

Injection attacks
• Injection - Tricking an application into including
unintended commands in the data sent to an
interpreter
• Interpreter
– Take strings and interpret them as commands
– SQL, OS Shell, LDAP, XPath, Hibernate, etc…
• SQL injection
– Many applications still susceptible
– Even though it’s usually very simple to avoid
6

Injection impact
• Usually severe.
• Entire database can usually
be read or modified
• May also allow full database
schema, or account access,
or even operating system
level access
7

Injection process
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
4. Database runs query containing attack and sends
encrypted results
5. back to application
6. Application decrypts data as normal and sends results
to the user
8

Injection Protection
• Avoid the interpreter entirely
• Use an interface that supports bind variables (e.g.,
prepared statements, or stored procedures),
– Bind variables allow the interpreter to distinguish between code
and data
• Encode all user input before passing it to the interpreter
• Always perform ‘white list’ input validation on all user
supplied input
• Always minimize database privileges to reduce the
impact of a flaw
9

Cross-Site Scripting (XSS)
• Cross-Site Scripting (XSS) - Raw data from
attacker is sent to an innocent user’s browser
• Raw data
– Stored in database
– Reflected from web input (form field, hidden
field, URL, etc…)
– Sent directly into rich JavaScript client
10

XSS Example
• Try this in your browser
• javascript:alert(document.cookie)
11

XSS Impact
• Steal user’s session, steal sensitive data, rewrite
web page, redirect user to phishing or malware
site
• Most Severe: Install XSS proxy which allows
attacker to observe and direct all user’s behavior
on vulnerable site and force user to other sites
12

XSS Protection
• Eliminate Flaw
– Don’t include user supplied input in the output page
• Defend Against the Flaw
– Primary Recommendation: Output encode all user
supplied input
– Perform ‘white list’ input validation on all user input to
be included in page
– For large chunks of user supplied HTML, use OWASP’s
AntiSamy to sanitize this HTML to make it safe
13

Session Management
• HTTP as a stateless protocol
– Credentials have to go with every request
– SSL should be used for everything requiring
authentication
• Session management flaws
– SESSION ID used to track state since HTTP
doesn’t
– SESSION ID is typically exposed on the network,
in browser, in logs
14

Session Management
• Methods
– Change my password
– Remember my password
– Forgot my password
– Secret question
– Logout
– email address
• Impact - User accounts compromised or user
sessions hijacked
15

Protection techniques
• Verify your architecture
– Authentication should be simple, centralized, and standardized
– Use the standard session id provided by your container
– Be sure SSL protects both credentials and session id at all times
• Verify the implementation
– Forget automated analysis approaches
– Check your SSL certificate
– Examine all the authentication-related functions
– Verify that logoff actually destroys the session
– Use WebScarab to test the implementation
16

Object references
• Caused by failed access control at the
presentation layer allowing attackers to modify
parameter values.
– Only listing the ‘authorized’ objects for the
current user, or
– Hiding the object references in hidden fields and
then not enforcing these restrictions on the
server side
• Impact - Users are able to access unauthorized
files or data
17

Example
• www.banking.com/user?acct=10579
• Attacker notices his acct parameter is 10579
?acct=10579
• He modifies it to a nearby number
?acct=10580
• Attacker views the victim’s account information
18

• Eliminate the direct object reference
• Replace them with a temporary mapping value
• ESAPI provides support for numeric & random
mappings
» IntegerAccessReferenceMap
» RandomAccessReferenceMap
• Validate the direct object reference
• Verify the parameter value is properly formatted
• Verify the user is allowed to access the target object
• Verify the requested mode of access is allowed to the
target object (e.g., read, write, delete)
19

Cross Site Request Forgery (CSRF)
• Cross Site Request Forgery (CSRF)
– An attack where the victim’s browser is tricked
into issuing a command to a vulnerable web
application
– Vulnerability is caused by browsers automatically
including user authentication data (session ID, IP
address, Windows domain credentials, …) with
each request
20

Impact
• Initiate transactions
– transfer funds
– close account
• Access sensitive data
• Change account details
21

• Add a secret, not automatically submitted, token to ALL
sensitive requests
– This makes it impossible for the attacker to spoof the
request
– Tokens should be cryptographically strong or random
• Don’t allow attackers to store attacks on your site
– Properly encode all input on the way out
– This renders all links/requests inert in most
interpreters
22

• Store a single token in the session and add it to
all forms and links
– Hidden Field: <input name="token"
value="687965fdfaew87agrde" type="hidden"/>
– Single use URL: /accounts/687965fdfaew87agrde
– Form Token: /accounts?auth=687965fdfaew87agrde …
• Use hidden fields so that the token in a referrer
header is not exposed
• Have a unique token for each function
• Require secondary authentication for functions
23

Questions

For assistance or additional information
• Phone: 216-664-1100
• Web: www.jurinnov.com
• Email: eric.vanderburg@jurinnov.com
• Twitter: @evanderburg
• Facebook: www.facebook.com/VanderburgE
• Linkedin: www.linkedin.com/in/evanderburg
• Youtube: www.youtube.com/user/evanderburg
JurInnov Ltd.
The Idea Center
1375 Euclid Avenue, Suite 400
Cleveland, Ohio 44115

Deconstructing website attacks - Eric Vanderburg

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to Deconstructing website attacks - Eric Vanderburg

Similar to Deconstructing website attacks - Eric Vanderburg (20)

More from Eric Vanderburg

More from Eric Vanderburg (20)

Recently uploaded

Recently uploaded (20)

Deconstructing website attacks - Eric Vanderburg