ted@tedneward.com | Blog: http://blogs.tedneward.com | Twitter: tedneward | Github: tedneward | LinkedIn: tedneward
The List
A1. Injection
A2. Broken Authentication and Session Management
A3. Cross-Site Scripting (XSS)
A4. Insecure Direct Object References
A5. Security Misconfiguration
The List
A6. Sensitive Data Exposure
A7. Missing Function Level Access Control
A8. Cross-Site Request Forgery (CSRF)
A9. Using Known Vulnerable Components
A10. Unvalidated Redirects/Forwards
Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
Prevention:
use a safe API which avoids the use of the interpreter entirely
use a safe API which provides a parameterized interface
carefully escape special characters (and consider all possible character representations)
prefer a "whitelist" approach to input validation
Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.
Prevention:
a single set of authentication and session mgmt controls
avoid XSS flaws that permit theft of session IDs
XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
Prevention:
properly escape all untrusted data based on the HTML context that the data will be placed into
prefer a "whitelist" approach to input validation
consider use of third-party libraries for input sanitization
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data
Prevention:
use per-user or -session indirect object references instead of database keys
check access to each/every object on every access
Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.
Prevention:
use products that are secure "out of the box"
a repeatable hardening process that makes it fast/easy to deploy another environment that is properly locked down
keep abreast of and deploy all new software updates/patches, including libraries
provide secure separation between components as part of the architecture
run scans and audits periodically
Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.
Which data is sensitive data?
Discuss:
is any of this data stored in clear text long term, including backups?
is any of this data transmitted in clear text?
are any old/weak crypto used?
are any browser security directives/headers missing when sensitive data is provided by / sent to the browser?
Prevention:
consider all attack vectors/threats relevant to this data
don't store sensitive data unnecessarily; discard it ASAP
use standard crypto algorithms, strong keys, and proper key management
disable autocomplete on forms collecting sensitive data
disable caching for pages that contain sensitive data
Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.
Prevention:
examine management of entitlements and ensure easy update and audit; don't hard code
enforcement mechanism(s) should deny all access by default (use "additive authorization")
if the function is involved in a workflow, make sure the conditions are in the proper state to allow access
A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
an application permits the user to submit a state-changing request that does not include anything secret
http://~/app/transferFunds?amount=1500&destinationAcct=452674
Attacker constructs a request that will transfer money from victim's account to the attacker's account. Then attacker embeds this attack in an image request or iframe stored on various sites under the attacker's control.
<img src="http://~/app/transferFunds?amount=1500&destinationAcct=452674" width="0" height="0" />
Prevention:
include an unpredictable unique-per-user-session token in each HTTP request
either in a hidden field
or (publicly) in the URL or URL parameter
require the user to reauthenticate or prove they are a user (CAPTCHA)
Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts
Prevention:
identify all components (and versions, including all dependencies) being used
monitor the security of these components; keep them up to date
establish security practices governing component use
consider adding security wrappers around components to disable unused functionality and/or secure weak/vulnerable aspects of the component
Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.
Prevention:
avoid using redirects/forwards
if used, don't involve user parameters in calculating the destination
if destination params cannot be avoided, ensure that the supplied value is valid and authorized for the user
additionally, any destination parameters should be a mapping value (not an actual URL target)
Websites** OWASP main--- https://www.owasp.org/index.php/Main_Page** OWASP Top Ten Web App Risks--- https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project** OWASP Top Ten Cheat Sheet--- https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet** OWASP Top Ten Mobile App Risks--- https://www.owasp.org/index.php/OWASP_Mobile_Security_Project** OWASP Developer's Guide Project--- https://www.owasp.org/index.php/OWASP_Guide_Project
your application IS vulnerable to one of these
you just haven't found it (them) yet
conduct a thorough security review
establish your threat model
examine your liability when/where a breach occurs
discuss with management how they want to proceed
keep in mind, some of these decisions are NOT yours to make
Who is this guy?
Architect, Engineering Manager/Leader, "force multiplier"
Co-founder, Solidify US
http://www.solidify.dev
Principal -- Neward & Associates
Author
Professional F# 2.0 (w/Erickson, et al; Wrox, 2010)
Effective Enterprise Java (Addison-Wesley, 2004)
SSCLI Essentials (w/Stutz, et al; OReilly, 2003)
Server-Based Java Programming (Manning, 2000)
See http://www.newardassociates.com