Do You Write Secure Code? by Erez Metula


Published on

Erez Metula at the alphageeks #4 meetup speaks about secure coding, common threats and how to address them.

Check us out at:

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Do You Write Secure Code? by Erez Metula

  1. 1. Do you write secure code? Erez Metula, CISSP Application Security Consultant & Trainer Agenda • What is application security • What are application level vulnerabilities • Demos • Security procedures • How to improve the development lifecycle
  2. 2. Growing concern What is Application Security? • It is not about network Security !!! • It’s not about Firewalls, Intrusion Detection Systems, It’ Operating System Hardening, Database Hardening, etc. • Network Security Mostly Ignores the Contents of HTTP Traffic • Common myth – “We have a firewall !“ !“ • It is about: • Securing the code that drives a web application • Securing backend systems – web server, DB, etc.. • Securing the users !!!
  3. 3. Application Security Is A Different World • Network Security • Application Security • Part of IT • Part of Business Units • Networking Experts • Software Experts • Product Focused • Custom Code Focused • 1000’s of Copies • 1 Copy of Software • Signature Based • No Signatures • Patch Management • Prevent Vulnerabilities We can’t rely on network security techniques to gain application security Application security layer
  4. 4. OWASP Top 10 (2010) DEMO – SQL Injection Developer concate SQL statements string sql = "select * from Users where user ='" + User.Text + "' and pwd='" + Password.Text + "'" pwd='" Hacker types: ‘ or 1=1 -- string sql = "select * from Users where a user =' ' or 1=1 --' and pwd=''" --' pwd=''" Result - the first database entry (might be the Admin!)
  5. 5. A little bit of humor.. DEMO – Directory traversal • The following demo shows an innocent looking page, letting the user to download a requested file from the base dir. • Legitimate use: • • But the user can get out of the base directory.. • file=../../progs/secret/SecretFile.pdf
  6. 6. DEMO - Cross-Site Scripting (XSS) • Web browsers execute code sent from websites • HTML • Javascript • Flash, etc. • send malicious code to other users • the attacker is using the website to forward an attack!<br>please login:<form<br>please action="" name=a action="" method="post">username:<br><input type=text method="post">username:<br><input name=b><br>password:<br><input type=password name=b><br>password:<br><input name=c><br><input class=w type=submit value="login"></form> name=c><br><input Demo – Denial of Service using XSS • Prevent legitimate users from using the hacmebank site (while true injection) <script>while(true){alert("service unavailable");}</script> <script>while(true){alert("service • Such a short line can cause so much damage..!!! • Other possibilities • Delete a specific user (competent?) • Change password for a specific user • Delete all the tables/database… tables/database… • Format the server HD
  7. 7. Business logic attacks • Flaws that allow a user to do something that isn't allowed by the business. • Cannot be detected by a vulnerability scanner • One of the hardest to detect • Specific to the application being tested. • Some examples • Negative amount of money • Skipping security checks • Performing operations in different order • DEMO • Withdraw becomes a deposit • Casino Cross Site Request Forgery (CSRF) • Another client side attack • Resembles XSS, but quite different • The victim’s browser is tricked into issuing a command to a vulnerable web application • The browser outgoing request automatically include user’s data (session id, authentication tickets, ip address, etc.) • Impact • Perform transactions on behalf of the user • Access private networks • Access sensitive data • Modify user’s data
  8. 8. CSRF Illustrated Attacker sets the trap on some website on the internet 1 (or simply via an e-mail) Application with CSRF Hidden <img> tag vulnerability contains attack against vulnerable site Communication Administration Bus. Functions E-Commerce Transactions Knowledge Accounts Finance Mgmt While logged into vulnerable site, 2 victim views attacker site Custom Code 3 Vulnerable site sees <img> tag loaded by legitimate request from browser – sends GET victim and performs the request (including action requested credentials) to vulnerable site CSRF via phishing e-mail Unusual activity.msg
  9. 9. CSRF via malicious web site • You visit a malicious web site • The web site instructs your browser to submit a request to some CSRF vulnerable page on the victim application • Your browser perform the operation • IE7 / Mozilla – at least an open tab • IE6 – from the same window • Example: • http://www. attacker. com/ csrf/ InnocentSite. What to do? • In order to avoid application level threats, we usually perform • Penetration testing • Code review • Threat modeling • SDL – Secure Development Lifecycle
  10. 10. Penetration Testing • Testing the security of systems and architectures from a hacker’s point of view hacker’ • Blackbox approach - A “simulated attack” attack” • Identifying weaknesses in already deployed targets, for example, platform tests include: • Information disclosure • Escalation of privileges to valid users • Denial of service • Unauthorized access • Penetration testing is usually done when development completes Problem - Cost of change
  11. 11. Code review • Security Code review is a process to improve software security by reviewing it “from the inside” inside” • Whitebox approach • This process should be performed by the developer and by a 3rd party security personnel • The main objective is to • Detect vulnerabilities in code • Identify bad application level configuration • Detect backdoors The Threat Modeling Threat Modeling Process 1 Identify Assets 2 Create an Architecture Overview 3 Decompose the Application 4 Identify the Threats 5 Document the Threats 6 Rate the Threats
  12. 12. We need secure development methodologies • Current development methodologies lack security procedures • Security should be performed from the initial project stages • Security should be embedded into the development lifecycle • SDL – Secure Development Lifecycle SDL “Integrate” Security within Application Life Cycle Security Threat Modeling Code Penetration Secure Requirements / Secure Design Review Testing Deployment Requirements Design Code Test Deploy Use Cases
  13. 13. Don’t rely on only one countermeasure …. Summary • Application security is different from other security layers • Traditional security products (firewall, antivirus, IPS, SSL, etc.) does not help to mitigate application threats. • You should perform application security by doing • Code review • Application penetration test • Design review • Integrate security into the development cycle • Example – SDL (secure Development Lifecyce) Lifecyce)
  14. 14. Questions ? Thank you !