The “Top 10” Web Application Security Risks

Murat Lostar

Why Web Application Security?

• Mid – late 90s.• Early – 2000s.• Today

• Tomorrow - Cloud, M2M• Always - People

OWASP – Top101. Injection 2. Broken Authentication

and Session Management

3. Cross-Site Scripting (XSS)4. Insecure Direct Object

References5. Security Misconfiguration

6. Sensitive Data Exposure7. Missing Functional Level

Access Control 8. Cross-Site Request

Forgery (CSRF)9. Using Known Vulnerable

Components10. Unvalidated Redirects and

Forwards

1. Injection

• Application sends untrusted data to an interpreter

• Types: SQL, LDAP, Xpath, NoSQL queries; OS commands; XML parsers, SMTP Headers, program arguments, etc.

Injection Example

• If exist (Select * from users where id= ‘@Name’ and pw= ‘@Pass’;) then logon successful

Injection Example

• Username: admin• Password: ‘ or 1=1 --

• If exist (Select * from users where id= ‘admin‘ and pw= ‘‘ or 1=1 --’;)

• Logon successful

Free Injection Scanner (example)• http://www.mavitunasecurity.com/

communityedition/

2. Broken Authentication and Session ManagementReinventing the wheel…… not quite.

Example: Session Fixation

3. Cross-Site Scripting (XSS)

• Using the vulnerable web site to attack another user (victim)

Different XSS Types

XSS

Persistent

Stored Distributed

Non-Persistent

Reflected DOM-Based

Combined

4. Insecure Direct Object References• User logs into the application• Can see own account information

http://example.com/app/accountInfo?acct=MyAcctNumber

• Is it possible to get other account infos?http://example.com/app/accountInfo?acct=NotMyAcctNumber

5. Security Misconfiguration

Questions to ask• Software out of date? (OS, Web/App Server, DBMS,

applications, and all code libraries) • Unnecessary features enabled or installed? (ports,

services, pages, accounts, privileges, …)• Default accounts and their passwords still the same?• Default error messages?• Insecure development frameworks settings?

6. Sensitive Data Exposure

• Data stored in clear text long term, including backups

• Data transmitted in clear text, internally or externally

• Old / weak cryptographic algorithms • Weak crypto keys generated /

No proper key management

Test yourself

• HTTPS/SSL: http://www.ssllabs.com/ssltest/

• EMAIL/TLS: http://www.checktls.com

7. Missing Functional Level Access Control • Using the URL independent of logon

process without authorization

8. Cross-Site Request Forgery (CSRF)• Money transfer app for the bank:

– GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

• Preparing false URL:– http://bank.com/transfer.do?acct=MARIA&amount=100000

• Trick the user to send this URL:– <a href="http://bank.com/transfer.do?

acct=MARIA&amount=100000">View my Pictures!</a>– <img src="http://bank.com/transfer.do?

acct=MARIA&amount=100000" width="1" height="1" border="0">

CSRF Testing

www.owasp.org/index.php/CSRFTester

9. Using Known Vulnerable Components• Using old, unpatched components within

applications• Most difficult to discover• Requires detailed inventory of components

to mitigate

10. Unvalidated Redirects and Forwards• http://www.example.com/redirect.jsp?

url=evil.com• http://www.example.com/boring.jsp?

fwd=admin.jsp• Check for spider 300-307 (302) responses

How to prevent/solve these?- %80 - %20 rule

Input validation• White-listing (BEST)• Black-listing• Sanitizing

• Data type• Data format• Data lenght

Use strong authentication

• Something you know– Passwords, PINS, etc

• Something you have– Mobile phones (SMS), bank cards, OTP, etc

• Something you are– Fingerprint, retina, voice, etc

Last words

• Web application security requires– Secure software lifecycle • Risk management• Security KPIs • Code security review (automated & automatic)

– Continuous monitoring and pen testing– Management commitment

Thank you.

• Murat Lostar– Linkedin.com/in/lostar– www.lostar.com

– Refs: OWASP, CERT, WIKIPEDIA, ISACA