Do you write
Erez Metula, CISSP
Application Security Consultant & Trainer
• What is application security
• What are application level vulnerabilities
• Security procedures
• How to improve the development lifecycle
What is Application Security?
• It is not about network Security !!!
• It’s not about Firewalls, Intrusion Detection Systems,
Operating System Hardening, Database Hardening, etc.
• Network Security Mostly Ignores the Contents of HTTP
• 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 !!!
Application Security Is A Different
• 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
OWASP Top 10 (2010)
DEMO – SQL Injection
Developer concate SQL statements
string sql = "select * from Users where
user ='" + User.Text + "'
and pwd='" + Password.Text + "'"
Hacker types: ‘ or 1=1 --
string sql = "select * from Users where a
user =' ' or 1=1 --' and pwd=''"
Result - the first database entry (might be the Admin!)
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..
DEMO - Cross-Site Scripting (XSS)
• Web browsers execute code sent from websites
• Flash, etc.
• send malicious code to other users
• the attacker is using the website to forward an attack!
name=c><br><input class=w type=submit value="login"></form>
Demo – Denial of Service using XSS
• Prevent legitimate users from using the hacmebank site
(while true injection)
• 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…
• Format the server HD
Business logic attacks
• Flaws that allow a user to do something that isn't allowed by the
• 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
• Withdraw becomes a deposit
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.)
• Perform transactions on behalf of the user
• Access private networks
• Access sensitive data
• Modify user’s data
Attacker sets the trap on some website on the internet
(or simply via an e-mail)
Application with CSRF
Hidden <img> tag vulnerability
contains attack against
While logged into vulnerable site,
2 victim views attacker site
Vulnerable site sees
<img> tag loaded by legitimate request from
browser – sends GET victim and performs the
request (including action requested
credentials) to vulnerable
CSRF via phishing e-mail
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
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
• Testing the security of systems and architectures from a
hacker’s point of view
• Blackbox approach - A “simulated 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
Problem - Cost of change
• Security Code review is a process to improve software
security by reviewing it “from the 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
We need secure development
• Current development methodologies lack security
• Security should be performed from the initial project stages
• Security should be embedded into the development lifecycle
• SDL – Secure Development Lifecycle
“Integrate” Security within Application Life Cycle
Security Threat Modeling Code Penetration Secure
Requirements / Secure Design Review Testing Deployment
Requirements Design Code Test Deploy
Don’t rely on only one countermeasure ….
• 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)