11/27/2018

Checking your Sponsored by

Application Against the

OWASP Top 10 Security
Risks

© 2018 Monterey Technology Group Inc.

 Made possible by

Thanks to

1
 11/27/2018

1. Injection
2. Broken Authentication
3. Sensitive Data Exposure
Preview of Key 4. XML External Entities (XXE)
Points 5. Broken Access Control
6. Security Misconfiguration
7. Cross-Site Scripting (XSS)
8. Insecure Deserialization
9. Using Components with Known Vulnerabilities
10. Insufficient Logging & Monitoring

Before we dive
 Web application security is hard
in…  Not all OWASP Top 10 risks created equally

2
 11/27/2018

User/Hostile Data
Web Application Tier x

1 Web Application Tier y

(No sanitation)
+ code
Injection

Web Application Tier z

Randy
Smith

1
[email protected]’) SOME BAD CODE

sql.run(“INSERT INTO registrants (fname,

lname, email) VALUES (‘” + req.fname
+”’,’”+ req.lname +”’,”+req.email)”

Injection INSERT INTO registrants (fname,

lname, email) VALUES (‘Randy’,’Smith’,
‘[email protected]’) SOME BAD CODE”

3
 11/27/2018

 SQL is most often thought of but also

 NoSQL
 OS command
 Object Relational Mapping (ORM)
 LDAP
 Expression Language (EL)
 Object Graph Navigation Library (OGNL)

1  Are you vulnerable?

 Identify all sources of untrusted input
 Is it sanitized and/or used by “safe” interfaces?
Injection  Sanitize with positive/whitelist input validation on the server-side
 Parameterized queries
 Object Relational Mapping Tools
 i.e. Entity Framework
 Requires
 scanning source code for
 unsafe query APIs
 tracing use of untrusted inputs
 Dynamic application testing of parameters, headers, URL, cookies, JSON,
SOAP, and XML data inputs

2  Very broad risk category involving vulnerabilities in any aspect of

authentication
 Credential lifecycle
Broken  Online authentication attacks
 Credential storage
Authentication  Off-line credential attacks
 Ineffective multi-factor
 Insecure Session ID handling

4
 11/27/2018

2  Credential lifecycle



Account registration
Password aging
Forgotten password reset & verification
Broken  Password strength
Authentication  More than length and complexity
 Check against common password lists
 NIST 800-63 B's guidelines in section 5.1.1 for Memorized Secrets or other
m

2  Online authentication attacks

 Credential stuffing
Broken  Brute force
 Limit or increasingly delay failed login attempts
Authentication  Check text of login messages to prevent against account enumeration

5
 11/27/2018

2  Credential storage


How does the web application store passwords and secrets?
Strong hash algorithm
Broken  Salt
 From A3: use strong adaptive and salted hashing functions with a work
Authentication factor (delay factor), such as Argon2, scrypt, bcrypt, or PBKDF2

 Ineffective multi-factor

2  Secret codes
 Just another password
 Security questions
Broken  Are you trying to protect against users whose PCs have been
Authentication compromised?
 Don’t depend on email or cookies
 Needs to be out-of-band and human-presence

6
 11/27/2018

 Insecure Session handling

 HTTP never designed for session based applications
 To maintain session-state

2  Pass it back and forth

 Keep identifier in cookie
 Pass session-ID back and forth in URL parameter

Broken  How is state maintained between web requests?

 Most web application frameworks handle this but
Authentication  Is it up-to-date?
 Are necessary security features used
 Insecure extensions?
 Session manager that generates a new random session ID with high entropy
after login. Session IDs should not be in the URL, be securely stored and
invalidated after logout, idle, and absolute timeouts.

 Also very broad

 Addresses sensitive data exposure
 Direct exposure

3  As a result of another vulnerability

 Applies to data
 At rest
Sensitive Data  In motion

Exposure  High reliance on encryption, so includes vulnerable encryption

execution
 Algorithms
 Key handling
 Enforcement with downstream agents/clients/systems

 So data is encrypted at rest

 But in what context is it transparently decrypted?

7
 11/27/2018

User/Hostile XML Data

Web Application Tier x

Reference

4 Web Application Tier y

(No sanitation)
XML External /etc/passwd

Entities (XXE)
XML Processor

 You’re authenticated and logged, now what are you permitted to do?

5  Not a question of what options are displayed to you in HTML

 It’s a matter of how the application responds to (hostile) data it
receives from the user
Broken Access  URL
 FORM
Control  etc
 Server-side application code must make no assumptions about
incoming requests and data or execution 0f client code

8
 11/27/2018

 Increasingly important the less trust you have in authenticated users

 But also important in context of stolen credentials
 Most web application frameworks focus access control on sections of the
application
 URL space

5
 Web pages
 Views
 But what about the data model?
 Record ownership
Broken Access  How many records returned?
 Rate limiting
Control  Very unique to business requirements and application domain
 Examples of exploits
 Bypassing access control checks by modifying the URL, internal application state,
or the HTML page, or simply using a custom API attack tool
 Allowing the primary key to be changed to another users record, permitting
viewing or editing someone else's account
 Elevation of privilege. Acting as a user without being logged in, or acting as an
admin when logged in as a user.
 Metadata manipulation, such as replaying or tampering with a JSON Web Token
(JWT) access control token or a cookie or hidden field manipulated to elevate
privileges, or abusing JWT invalidation

 Not so much broad as just very massive

6  Security misconfiguration at any level of application stack



Network services
Platform
Security  Web server
Misconfi-  Application server
 Database
guration  Frameworks
 Components
 Storage
 Containers

9
 11/27/2018

 Type of injection, in which malicious scripts are injected into otherwise

benign and trusted websites

7  Attacker uses a web application to send malicious code, generally in

the form of a browser side script, to a different end user
 Can occur anywhere a web application uses input from UserA within
the output it generates and sends to UserB
Cross-Site  without validating or encoding it
Scripting  How different than injection?
 Both based on using unsanitized input from untrusted sources
(XSS)  Injection – input is passed down to lower tiers of application where it’s
interpreted and exploited
 Target is the web application
 XSS – results in client side code being executed in the context of another
user
 Target is normally the client

7  3 forms of XSS
Cross-Site  Stored XSS
Scripting  Reflected XSS
 DOM XSS
(XSS)

10
 11/27/2018

 Stored XSS
 Classic example: discussion forum

7
Cross-Site
Scripting Website Storage
(XSS)

 Reflected XSS
 Find a vulnerable page on website
 Stuff some JavaScript into the URL
 Get user to click link
 JavaScript bounces off the server back to the browser where it’s

7
executed
 Allows attacker to execute arbitrary JavaScript in the vulnerable
web application

Cross-Site
Scripting
(XSS) Website

11
 11/27/2018

 DOM XSS
 Find a web page on a target web application that displays data from the
URL
 Stuff some javascript into hash portion of URL

7  JavaScript executes in context of web application without payload ever

hitting the web server

Cross-Site
Scripting
(XSS) Website

Escape untrusted HTTP request

data based on the context in the
HTML output (body, attribute,
 3 forms of XSS JavaScript, CSS, or URL)

7
 Stored XSS
 Classic example: discussion forum
 Reflected XSS
 Find a vulnerable page on website
 Stuff some JavaScript into the URL
Cross-Site  Get user to click link Context-sensitive encoding when
Scripting 

JavaScript bounces off the server modifying
Allows attacker to execute arbitrary
the browser
back to the browser
on the client in
JavaScript side
where document
theacts
it’s executed
against
vulnerable webDOM
(XSS)  DOM XSS
application XSS

 Find a web page on a target web application that displays data from the URL
 Stuff some javascript into hash portion of URL
 JavaScript executes in context of web application without payload ever
hitting the web server

12
 11/27/2018

 Serialization is a powerful way to save programming language objects

8 to a data stream for transportation and/or storage then re-instantiate

them in memory later or on another system
 Remote- and inter-process communication (RPC/IPC) • Wire protocols,
web services, message brokers • Caching/Persistence • Databases, cache
Insecure servers, file systems • HTTP cookies, HTML form parameters, API
authentication tokens
Deserialization  An attacker who can specify or tamper with serialized data can create
new/different objects with arbitrary data in the memory of the
deserializing process

Client Server

Request Quote
Quote
Line
Item

8 Serializer

Insecure
Serialized
Deserialization Data
Tamper

DeSerializer

Payment

13
 11/27/2018

8  Vulnerable?
 Is data serialization used?
 Is serialized data ever passed through or received from untrusted parties?

Insecure  Prevention
 Don’t to accept serialized objects from untrusted sources
Deserialization  Use serialization mediums that only permit primitive data types
 As long as those data aren’t important to security
 Type restrictions on deserialization
 Integrity checks

 Today’s software
development is
component-heavy
 Components use

9 components
 Developers often
have free reign to
Using download and
include new
Components components in
applications
with Known  Hugely important to
fast, maintainable
Vulnerabilities development
 Hugely risky as
well
 I love nuget but
 https://haacked.c
om/archive/2013/0
2/19/trust-and-
nuget.aspx/

14
 11/27/2018

10
Insufficient  Log everything
 Including errors
Logging &  Monitor your logs
Monitoring  Including errors

 Securing web applications

 Safe coding techniques and policies
 Understanding the multi-tier stack of web applications
 Understanding how web applications are full of exposures to untrusted
parties/sources
 Multiple contexts of execution
 Escape, encode and sanitize data before storing, using, interpreting or rendering
 Use encryption and integrity checking
 Understand session state

Bottom line  Garrett will briefly show you:

 Anatomy of an injection attack
 history
 types
 exploitation example
 Identifying injection vulnerabilities
 DAST, SAST, RASP vs penetration testing
 modern web app challenges
 mitigating injection vulnerabilities
 prepared statements w/ parameterized queries
 stored procedures
 whitelisting input
 escaping user input entirely

 Note: This abstract and the OWASP Top 10 document is licensed under a
Creative Commons Attribution-ShareAlike 4.0 International license:
https://creativecommons.org/licenses/by-sa/4.0/
2018 Monterey Technology Group Inc.

15
 11/27/2018

Operating in Silos

Start Your Free 30-Day Trial

Gain unrestricted access to InsightAppSec's powerful
features and start scanning with one of own applications

https://www.rapid7.com/try/insightappsec?CS=UWS

16