February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 1
OWASP Foundation – Los Angeles Chapter
http://www.owaspLA.org
Twitter: @owaspla
Email: [email protected]
Monthly meetings, 4th Wednesday of each month
Tin Zaw, Chapter Leader
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 3
(1) Query Parameterization (PHP PDO)
$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)");
$stmt->bindParam(':name', $name);$stmt->bindParam(':value', $value);
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 4
XSS: Why so Serious?
Session hijackingSite defacementNetwork scanningUndermining CSRF defensesSite redirection/phishingLoad of remotely hosted scriptsData theftKeystroke logging
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 5
(2) XSS Defense by Data Type and Context
Data Type Context Defense
Numeric, Type safe language
Doesn’t Matter Cast to Numeric
String HTML Body HTML Entity Encode
String HTML Attribute, quoted Minimal Attribute Encoding
String HTML Attribute, unquoted
Maximum Attribute Encoding
String GET Parameter URL Encoding
String Untrusted URL URL Validation, avoid javascript: URL’s, Attribute encoding, safe URL verification
String CSS Strict structural validation, CSS Hex encoding, good design
HTML HTML Body HTML Validation (JSoup, AntiSamy, HTML Sanitizer)
Any DOM DOM XSS Cheat sheet
Untrusted JavaScript Any Sandboxing
JSON Client parse time JSON.parse() or json2.js
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 6
Danger: Multiple Contexts
Browsers have multiple contexts that must be considered!
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 7
CSS Pwnage Test Case
<div style="width: <%=temp3%>;"> Mouse over </div>
temp3 = ESAPI.encoder().encodeForCSS("expression(alert(String.fromCharCode (88,88,88)))");
<div style="width: expression\28 alert\28 String\2e fromCharCode\20 \28 88\2c 88\2c 88\29 \29 \29 ;"> Mouse over </div>
Pops in at least IE6 and IE7. lists.owasp.org/pipermail/owasp-esapi/2009-
February/000405.html
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 8
Simplified DOM Based XSS Defense
1. Initial loaded page should only be static content. 2. Load JSON data via AJAX.3. Only use the following methods to populate the
DOM Node.textContent document.createTextNode Element.setAttribute
References: http://www.educatedguesswork.org/2011/08/guest_post_adam_barth_on_three.html and Abe Kang
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 9
Dom XSS Oversimplification DangerElement.setAttribute is one of the most
dangerous JS methods If the first element to setAttribute is any of
the JavaScript event handlers or a URL context based attribute ("src", "href", "backgroundImage", "backgound", etc.) then pop.
References: http://www.educatedguesswork.org/2011/08/guest_post_adam_barth_on_three.html and Abe Kang
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 10
Best Practice: DOM Based XSS Defense I
Untrusted data should only be treated as displayable text JavaScript encode and delimit untrusted data as quoted
strings Use document.createElement("…"),
element.setAttribute("…","value"), element.appendChild(…), etc. to build dynamic interfaces
Avoid use of HTML rendering methods Understand the dataflow of untrusted data through your
JavaScript code. If you do have to use the methods above remember to HTML and then JavaScript encode the untrusted data
Make sure that any untrusted data passed to eval() methods is delimited with string delimiters and enclosed within a closure or JavaScript encoded to N-levels based on usage and wrapped in a custom function
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 11
Limit the usage of dynamic untrusted data to right side operations. And be aware of data which may be passed to the application which look like code (eg. location, eval()).
When URL encoding in DOM be aware of character set issues as the character set in JavaScript DOM is not clearly defined
Limit access to properties objects when using object[x] access functions
Don’t eval() JSON to convert it to native JavaScript objects. Instead use JSON.toJSON() and JSON.parse()
Run untrusted script in a sandbox (ECMAScript canopy, HTML 5 frame sandbox, etc)
Best Practice: DOM Based XSS Defense II
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 12
Attacks on Access Control
Vertical Access Control Attacks A standard user accessing administration functionality “Privilege Escalation”
Horizontal Access Control attacks Same role, but accessing another user's private data
Business Logic Access Control Attacks Abuse of workflow
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 13
Attacking Access Control Impact
Elevation of privileges Disclosure of confidential data Compromising admin-level accounts often results in
access to user’s confidential data Data tampering Privilege levels do not distinguish users who can
only view data and users permitted to modify data
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 14
Access Control Anti-Patterns
Hard-coded role checks in application code Lack of centralized access control logic Untrusted data driving access control decisions Access control that is “open by default” Lack of addressing horizontal access control in
a standardized way (if at all) Access control logic that needs to be manually
added to every endpoint in code
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 15
(3) Access Control Positive Patterns
Code to the activity, not the role Centralize access control logic Design access control as a filter Deny by default, fail securely Build centralized access control mechanism Apply same core logic to presentation and
server-side access control decisions Server-side trusted data should drive access
control
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 16
Best Practice: Code to the Activity
if (AC.hasAccess(ARTICLE_EDIT)) {
//execute activity
}
Code it once, never needs to change again Implies policy is persisted/centralized in some
way Requires more design/work up front to get right
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 17
Best Practice: Use a Centralized Access Controller
In Presentation Layer
if (isAuthorized(VIEW_LOG_PANEL)){
<h2>Here are the logs</h2><%=getLogs();%/>
}
In Controller
try (assertAuthorized(DELETE_USER)){
deleteUser();}
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 18
Danger: Hard Coded Roles
if (user.isManager() ||
user.isAdministrator() ||
user.isEditor() ||
user.isUser())
{
// execute action
}
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 19
Danger: Hard Coded Roles
Makes “proving” the policy of an application difficult for audit or Q/A purposes.
Any time access control policy needs to change, new code need to be pushed.
Fragile, easy to make mistakes
Compliance audits often fail applications specfiically for this issue
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 20
Danger: Order Specific Operations
Imagine the following parametershttp://example.com/buy?action=chooseDataPackage
http://example.com/buy?action=customizePackage
http://example.com/buy?action=makePayment
http://example.com/buy?action=downloadData
Can an attacker control the sequence?
What step would an attacker like to skip?
Can an attacker abuse this with concurrency?
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 21
Danger: Never Depend on Untrusted Data for Access Control Decisions
Never trust user data for access control decisions
Never make access control decisions in JavaScript
Never make authorization decisions based solely on anything from the request
Never depend on the order of values sent from the client
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 22
Danger: Access Control Administration Issues
Many administrative interfaces require only a password for authentication
Shared accounts combined with a lack of auditing and logging make it extremely difficult to differentiate between malicious and honest administrators
Administrative interfaces are often not designed as “secure” as user-level interfaces given the assumption that administrators are trusted users
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 23
Best Practice: Other Access Control Considerations
Log all failed access authorization requests to a secure location for review by administrators
Avoid assigning permissions on a per-user basis
Perform consistent authorization checking routines on all application pages (Filter?)
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 24
Cross Site Request Forgery (CSRF)
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 25
Attacking Sensitive Transactions
Once authenticated, users are trusted throughout the lifetime of their session
Applications do not require users to re-authenticate when executing sensitive transactions
Cross-Site Request Forgery (XSRF/CSRF) Attacks the trust a web application has for authenticated users Browser instances share cookies Users typically browse multiple sites simultaneously Attackers can abuse the shared cookie jar to send requests as
the authenticated user
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 26
Anatomy of an CSRF Attack
Consider a consumer banking application that contains the following form
<form action=“https://bank.com/Transfer.asp” method=“POST” id=“form1”>
<p>Account Num: <input type=“text” name=“acct” value=“13243”/></p>
<p>Transfer Amt: <input type=“text” name=“amount” value=“1000” /></p>
</form>
This form will generate requests that resemble the followingGET http://www.example.com/Transfer.asp?acct=##&amount=##
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 27
(4) Cross Site Request Forgery Defenses
Cryptographic Tokens Primary and most powerful defense. Randomness is your friend.
Request that cause side effects should use (and require) the POST method
Alone, this is not sufficient
Require users to re-authenticate Amazon.com does this *really* well
Double-cookie submit Decent defense, but no based on randomness, based on SOP I tend to not recommend this
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 28
Authentication Dangers
Weak password Login Brute Force Username Harvesting Session Fixation Weak or Predictable Session Plaintext or poor password storage Weak "Forgot Password” feature Weak "Change Password” feature Credential or session exposure in transit via
network sniffing Session Hijacking via XSS
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 29
Login Functionality Attacks
Username enumeration which allows an attacker to enumerate valid usernames for use with further attacks
Password guessing which is most successful when users are allowed to choose weak passwords
Brute-Force Attacks which succeeds when there is no account lockout or monitoring of login attempts
Credential Theft which succeeds when there is no encryption protecting credentials stored or in transit
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 30
(5) Authentication Defenses
Develop generic failed login messages that do not indicate whether the user-id or password was incorrect
Enforce account lockout after a pre-determined number of failed login attempts
Account lockout should trigger a notification sent to application administrators and should require manual reset (via helpdesk)
Implement server-side enforcement of password syntax and strength (i.e. length, character requirements, etc)
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 31
Require identity and security questions Last name, account number, email, DOB Enforce lockout policy Ask one or more good security questions
http://www.goodsecurityquestions.com/
Send the user a randomly generated token via out-of-band method email, SMS or token
Verify code in same web session Enforce lockout policy
Change password Enforce password policy
(6) Forgot Password Secure Design
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 32
Attacking A Session Identifier
If session identifiers are issued in a predictable fashion, an attacker can use a recently issued Session ID to guess other valid values
If the possible range of values used for Session ID’s is small, an attacker can brute force valid values
Session ID’s are also susceptible to disclosure via network sniffing attacks
Once obtained, a session ID typically allows impersonation of the userSusceptible to replayNo need to steal user credentials
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 33
Ensure secure session ID’s20+ bytes, cryptographically randomStored in HTTP CookiesCookies: Secure, HTTP Only, limited path
Generate new session ID at login timeTo avoid session fixation
Session Timeout Idle TimeoutAbsolute TimeoutLogout Functionality
(7) Core Session Defenses
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 34
(8) Session Cookie Defenses
Path The path under which all requests should receive the
cookie. “/” would indicate all paths on the server Domain
The domain for which servers should receive the cookie (tail match). For example, my.com would match all hosts within that domain (www.my.com, test.my.com, demo.my.com, etc.)
Secure Indicates that the cookie should only be sent over
HTTPS connections HTTPOnly
Helps ensure Javascript can not manipulate the cookie. Good defense against XSS.
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 35
(9a) Secure Password Storage
public String hash(String plaintext, String salt, int iterations)
throws EncryptionException {
byte[] bytes = null;
try {
MessageDigest digest = MessageDigest.getInstance(hashAlgorithm);
digest.reset();
digest.update(ESAPI.securityConfiguration().getMasterSalt());
digest.update(salt.getBytes(encoding));
digest.update(plaintext.getBytes(encoding));
// rehash a number of times to help strengthen weak passwords
bytes = digest.digest();
for (int i = 0; i < iterations; i++) {
digest.reset(); bytes = digest.digest(bytes);
}
String encoded = ESAPI.encoder().encodeForBase64(bytes,false);
return encoded;
} catch (Exception ex) {
throw new EncryptionException("Internal error", "Error");
}}
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 36
(9b) Discourage Browser Password Storage
Disable Browser Autocomplete <form AUTOCOMPLETE="off”> <input AUTOCOMPLETE="off”>
Only send passwords over HTTPS POST
Do not display passwords in browser Input type=password Do not display passwords in HTML document
February 2012 Top Ten Controls v1 Eoin Keary and Jim Manico Page 37
(10) Encryption in Transit (TLS)
Authentication credentials and session identifiers must me be encrypted in transit via HTTPS/SSLStarting when the login form is renderedUntil logout is completeAll other sensitive data should be protected via
HTTPS!
https://www.ssllabs.com free online assessment of public facing server HTTPS configuration
https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet for HTTPS best practices