Insecure software undermines our infrastructure and puts our organizations at risk. Whether you’re a new developer, a designer who is beginning to experiment with programming, or a seasoned developer looking for a refresher, join us as we discuss why attacks happen, go over the most common vulnerabilities and techniques you can use to code defensively. This hands-on workshop will feature real-world hacking exercises that correspond to each of the Open Web Application Security Project (OWASP) top 10 vulnerabilities, helping to hone your skills as a security ninja!
Report
Share
Report
Share
1 of 84
Download to read offline
More Related Content
Become a Security Ninja
1. BECOME A SECURITY NINJA
Don’t let your code be low-hanging fruit
Paul Gilzow
gilzow@missouri.edu
Twitter: @gilzow
Facebook: /gilzow
https://www.linkedin.com/in/gilzow
2. What we will talk about
Get our example files up and running
What is OWASP
What is the OWASP Top 10
The Current Top 10 Web Security Risks
ATTACK!
3. Set Up Our Exercise files
Log into your Digital Ocean account
https://cloud.digitalocean.com/login
4. Set Up Our Exercise files
Click on “Create Droplet”
5. Set Up Our Exercise files
Choose a size
Click on “One-click apps”
7. Set Up Our Excersice files
Scroll to the bottom of the page
Click the “Create” button
8. Set Up Our Excersice files
Once the instance is created, check your email for the credentials
In your ssh client, log into your new instance
9. Set Up Our Excersice files
You’ll need to change your password the first time you login
10. Set Up Our Excersice files
At the prompt type in
docker run -d -p 8899:80 opendns/security-ninjas
Docker will download and install the security-ninjas container
11. Set Up Our Excersice files
Open your browser and go to your droplet ip address, port 8899
e.g. http://45.55.167.245:8899
12. What is OWASP
Open Web Application Security Project
Worldwide non-project organization focused on
improving software security by raising awareness
Started in 2001
Hundreds of local chapters throughout the
world, with over a hundred in the U.S.
13. Current State of Web App security
160% increase in websites hosting malware between
2015 and 20161
55% of web apps have at least one high-severity
vulnerability, up 9% from 2015 to 20162
84% are suscptible to at least one medium-serverity
vulnerability2
Average of 15 vulnerabilities per site3
1 - Google Transparency Report, 2016
2 - Acunetix Web Application Vulnerability report 2016
3 - White Hat Security Web Applications Security Statistics Report 2016
14. Education, 49% of sites had at least one vulnerability
every day of the year1
Education, average of 28 vulnerabilities per site, 15 of
those serious1
Education, took an average of 4 months to remediate
issues1
1 - White Hat Security Web Applications Security Statistics Report 2016
Education Industry
Current State of Web App security
15. Why Education is an attractive target
Network capacity and availability
Rich in hardware infrastructure
Poor in human resources
Resistant to blacklisting
SEO reputation
Personally Identifiable Information (PII) / Sensitive Personal Information
(SPI)
Confidential Research Data / Proprietary Intellectual Property
16. What is the OWASP Top 10
Not a standard, but an awareness document
10 Most Critical Web Application Security Risks
For each risk, it includes
Description
Example vulnerabilities
Example Attacks
Guidance on how to avoid
First released in 2003, refreshed every 3 years
Current version is from 2013, next version due out late this year, early 2017
17. Current Top 10 (as of 2013)
1. Injection
2. Broken Authentication and Session Management
3. Cross-Site Scripting (XSS)
4. Insecure Direct Object Reference
5. Security Misconfiguration
6. Sensitive Data Exposure
7. Missing Function Level Access Control
8. Cross-Site Request Forgery (CSRF)
9. Using Components with Known Vulnerabilities
10. Unvalidated Redirects and Forwards
18. A1. Injection
• Untrusted/tainted data is sent to an interpreter
as part of a command or query.
• Interpreter is tricked into executing unintended
commands
What is it?
21. A1. Injection
• Failure to separate untrusted data with commands sent
to an interpreter
• Lack of input validation and/or input sanitation
• Attacker is able to change execution context
Why does it happen?
22. A1. Injection
• SQL Injection
SELECT UserId, Name, Password FROM Users WHERE UserId = $input;
Becomes
SELECT UserId, Name, Password FROM Users WHERE UserId = 105 or 1=1;
Examples
24. A1. Injection
• Use APIs that provide parameterized/sanitized
interfaces
• Validate input against a whitelist (do NOT use a
blacklist)
• Escape any special characters that you whitelist
Prevention
25. A2. Broken Authentication and
Session Management
• Failure to protect credentials and session tokens
throughout the lifecycle of the session
• Weak authentication logic
• Imperfect implementation
What is it?
26. A2. Broken Authentication and
Session Management
• Passing the session ID as a parameter in the URL
• Using a predictable value for the session ID
• User credentials passed unencrypted
• Poor username and password recovery functions
Why does it happen?
28. A2. Broken Authentication and
Session Management
• Never send credentials/sensitive data in the clear; use SSL
• Protect secrets throughout their lifecycle
• Don’t expose credentials (including session IDs) in the URL or logs
• Use centralized authentication and session management APIs, if available
• Implement strong account management functions (e.g., account creation,
change password, recover password, etc.)
• Use strong algorithms to generate (random) secrets
• Do not rely on untrustworthy information for authentication (e.g. IP address,
referrer, etc.)
Prevention
29. A2. Broken Authentication and
Session Management
• Use a different session ID after authentication or
whenever authorization/permission levels change
• Destroy/invalidate the session ID completely after the
log out method has completed
• Enforce session timeouts
• Protect against Cross-Site Scripting (XSS)
Prevention
30. A3. Cross-Site Scripting (XSS)
• Similar to injection, but the intended target is a user’s
browser: the user’s browser is tricked into executing
unintended commands
• Usually in the form of HTML code or client-side scripts
• Occurs when an application takes unstrusted data from
the user and sends it back to the browser without
validation or encoding
• Exploits the trust the user has for a site
What is it?
31. If an attacker controls your browser, it is no longer
your browser
32. A3. Cross-Site Scripting
• Failure to separate untrusted data with commands
• Lack of input validation and/or input sanitation
• Attacker is able to change execution context
Why does it happen?
34. A3. Cross-Site Scripting
• Data from the URL is used in the creation of the page
• Attacker tricks/entices user to click the exploited URL
• Web application reflects the payload back to the user’s
browser where it is executed as if it came from the
originating site
Types: Reflected
36. A3. Cross-Site Scripting
• Injected script is stored on the target server
• The injection script is then sent to visitors of the site
• Vicitim’s browser then executes the injected script as it
believes it came from the originating site
• Delayed (aka “Blind”) refers to the payload being
executed at a later time, possibly in a completely different
system (e.g. Log viewers, customer service apps, etc.)
Types: Stored/Persistent
37. A3. Cross-Site Scripting
• Similar to reflected but instead of tricking the user’s browser to
exectute script, tricks legitimate client side script into executing
the payload
• The attack payload is executed as a result of modifying the
DOM environment in the victim’s browser used by the original
client side script, so that the client side code runs in an
unexpected manner
• More prevalent now than in the past due to the increase use in
javascript and vulnerable javascript libraries (almost 200%
increase between 2015 and 20161
)
Types: Dom-based (aka Client Side)
1 - Acunetix web application vulnerability report 2016, pg 5
41. A3. Cross-Site Scripting
• Implicitly deny
• Validate all input, regardless of where it
comes from
• Context-based output encoding
Prevention
42. A3. Cross-Site Scripting
• HTML Element Content
<div>DATA</div>
• HTML Attribute Values
<input name=“DATA” type=“text” value=“DATA” />
• Javascript Data
<script>someFunc(‘DATA’);</script>
• CSS Property Values
.foo a:hover{ color: DATA }
• URI Attribute VAlues
<a href=“/search/?q=DATA”>
Prevention - Context-based output encoding
• ( &, <, >, “) —> &entity;
( ‘, / ) —> &#DDD; or &#xHH;
(UTF-8 encode)
• All non-alphanumeric —> &#xHH;
• All non-alphanumeric —> xHH
• All non-alphanumeric —> HH
• All non-alphanumeric —> %HH
43. A3. Cross-Site Scripting
• Implicitly deny
• Validate all input, regardless of where it comes from
• Context-based output encoding
• Content-Security-Policy headers
Prevention
44. A3. Cross-Site Scripting
Set of HTTP Response headers (or can be implemented
via meta element) that defines where resources can be
loaded from, preventing users’ browser from loading data
from any other locations.
Header Set Content-Security-Policy: script-src 'self' https://apis.google.com
<meta http-equiv="Content-Security-Policy" content="default-src 'self'">
Prevention - Content-Security-Policy headers
47. A4. Insecure Direct Object References
• Occurs when a reference to an internal implementation
object (file, directory, database record/key) is exposed
as a URL or form parameter
• Without subsequent authorization checks, an attacker
can manipulate these parameters to access
unauthorized data
What is it?
51. A4. Insecure Direct Object References
• Do not expose internal keys or identifiers for
objects
• Use object references that are difficult to guess
• Perform server-side authorization checks for object
access
Prevention
52. A5. Security Misconfiguration
• Security issues anywhere in the stack
• Framework
• Application Server
• Web Server
• Database Server
• Operating System
• 3rd party contols/modules
What is it?
53. A5. Security Misconfiguration
• Application dumps stack trace or reveals other
debugging information
• Default passwords not changed
• Out-of-date software
• Directory listings enabled
Examples
55. A5. Security Misconfiguration
• Security hardening throughout the entire application
stack
• Change default passwords
• Disable/remove debugging message and overly
informative error messages in production
• Remove unnecessary/unused features/modules/
components
Prevention
56. A6. Sensitive Data Exposure
• Storing and transmitting sensitive data insecurely, due to:
• Failure to identify all sensitive data
• Failure to identify all locations where sensitive data is
stored (database, files, logs, backups, etc)
• Failure to identify all locations sensitive data is sent
(web, databases, internal communications, external
business partners)
What is it?
57. A6. Sensitive Data Exposure
• Debugging information in comments of ouput
sent to the browser
• Application that stores sensitive data (correctly)
encoutners an error and logs that data
insecurely
Examples
61. A6. Sensitive Data Exposure
• Don’t store sensitive data if you don’t need it
• Catalog all sensitive data and where it is used
• Disable caching of pages that contains sensitive data
• Encrypt all sensitive data at rest and in transit
• Use strong standard algorithms and strong keys
Prevention
62. A7. Missing Function Level Access Controls
• Enforcing proper authorization for requests
What is it?
64. A7. Missing Function Level Access Controls
• Attacker notices the URL structure indicates his role
https://example.com/user/getAccount
• Attacker modifies it to another role
https://example.com/admin/getAccount
• The application fails to do a server-side check to verify
the request is coming from a user with the proper
authorization and the attacker now has access to data
on any account
Examples
66. A7. Missing Function Level Access Controls
• Deny by default
• Perform server-side checks for every
function/action that requires authorization
• Server-side checks should not rely soley on
information provided by the client
Prevention
67. A8. Cross-Site Request Forgery
• Victim’s browser is tricked into issuing commands to a
vulnerable web application, to perform an unwanted action on a
trusted site for which the user is currently authenticated.
• Web browsers automatically include credentials (cookies,
sessions, basic authentication headers) with each request, even
for requests initiated by a form, script or image on another site
• Server-side code processes requests as if they came from the
authenticated user
• Often combined with Cross-Site Scripting
What is it?
68. A8. Cross-Site Request Forgery
• Application is built to allow a state change via URL
parameters
http://bankx.com/app?action=transfer&amount=3500&destinationAccount=4673243243
• Attacker constructs a request that will transfer funds to
to their account and embeds the requests on sites he
controls. He then tricks the victim into visiting the site
Examples
<img src="http://bankx.com/app?action=transfer&amount=14000&destinationAccount=attackersAcct#" width="0" height="0" />
70. A8. Cross-Site Request Forgery
• Eliminate all XSS vulnerabilities in your application
• Never allow changes to data via a GET request
• Check Origin and Referer headers as a first step
• Include a per-request, cryptographically strong or
random token to all forms, where the verification token is
not provided by the browser
• Require reauthentication for sensitive transactions
Prevention
71. A9. Using Components with Known Vulnerabilities
• Using third-party controls/modules/frameworks with
known vulnerabilities anywhere in the stack can be
discovered and exploited by automated tools
• Third-party libraries/frameworks in an application
typically run with the same privileges as the application
• Those vulnerabilities can undermine other defenses
What is it?
73. A9. Using Components with Known Vulnerabilities
• Identify all third-party components in your applications, and
potentially throughout the entire stack
• Uninstall/disable all third-party components that are not being
used
• Monitor the security of these components in public databases
(CVE, NVD, etc.), security mailing lists
• Keep third-party components up-to-date religiously
• Develop a security policy on third-party component use
Prevention
74. A10. Unvalidated Redirects and Forwards
• Application takes input from an external source that is
then used to formulate a redirection or forward location
without validation
• Attacker links to an unvalidated redirect and tricks
victims into clicking it. Victims are more likely to click on
it, since the link is to a valid site
https://www.irs.gov/taxrefund/claim.jsp?
year=2015&dest=ev.il/sDfX4
What is it?
75. A10. Unvalidated Redirects and Forwards
• Application uses forwards to route requests between
different parts of the site. Pages use a parameter to
indicate where the user should be sent if a transaction
is successful.
• Attacker crafts a URL that will pass the application’s
access control check (or is missing control checks) and
then forwards the attacker to administrative
functionality for which the attacker isn’t authorized.
What is it?
77. A10. Unvalidated Redirects and Forwards
• Don’t use them unless you absolutely have to
• Avoid using user input to detemine destination URL
• Whitelist allowed pages or external sites
• Ensure URL is valid and authorized for the user
Prevention
82. Developer Take-aways
• Security is a process, not an event
• Build security into the software development life-cycle
• Be paranoid; be skeptical
• Treat all data as tainted
• Validate data first (whitelist), then filter (blacklist)
• Validate/clean as early in the process as possible
• Encode data appropriately before sending to the client
• Never rely on client-side checks
83. Developer Take-aways
• Defense-in-depth
• Principle of Least Privilege
• Limit access to everything
• Enforce strong passwords
• Don’t harcode secrets in source code
• Keep third-party components up-to-date
• Error handling and Debug information
Continued