_experience the commitment

TM

Securing Web 2.0: Are Your Web Applications Vulnerable?

By Ken Huang and James Hewitt, CGI NYS Cyber Security Conference 2010

Agenda

Web 2.0 Defined Top Web 2.0 security vulnerabilities Secure development of Web 2.0 applications

What is Web 2.0?

Social Websites: LinkedIn, Facebook, Twitter Sharing: blog, wiki, forum, and user groups Mashup: Google Mashup Editor, Google Maps API, Yahoo Pipes, Microsoft Popfly, Yahoo! Widgets and Google Gadgets User Generated

Examples of Web 2.0 Sites

Blog Photo sharing Wiki Forums Facebook

Technologies used in Web 2.0

AJAX: Asynchronous JavaScript and XML. JSON: JavaScript Object Notation REST: Representational State Transfer SOAP: Simple Object Access Protocol RSS: Really Simple Syndication Flash: Adobe Flasher video player

Insufficient Authentication

_experience the commitment

TM

Countermeasures as a Web 2.0 User

Use strong passwords Don t put your birthday or other personal information on Facebook or other social websites

Countermeasures as a developer or administrator

Enforce strong password policy Disable autocomplete Enforce session timeouts Forgot Password Questions must be not easy to answer.

XSS: Cross Site Scripting

XSS: May 11, 2010 on Yelp

11

XSS in WhiteHouse.gov May 10, 2010

Cross Site Request Forgery (XSRF)

13

Example of XSRF

14

_experience the commitment

TM

_experience the commitment

TM

Countermeasures as a Web developer

Don t trust any user input Best: Use white list approach Blacklist approach Mixed approach Escape and encode input Session Management

Information Leakage in Social Websites

Sarah Palin's private e-mail hacked, posted to Net

18

_experience the commitment

TM

_experience the commitment

TM

_experience the commitment

TM

_experience the commitment

TM

Facebook Privacy Settings

23

Disable public search for your Facebook account

24

Countermeasures as a Web Developer

Authentication and Access Control Example: Recent iPad data loss was due to the lack of access controls for a script on the AT&T website.

25

Injection Flaws
SQL injection XML injection JSON injection E-mail injection

26

_experience the commitment

TM

_experience the commitment

TM

Countermeasures as a Web Developer

Do not use dynamic statements Escape or encode meta characters Validate input Authentication and access control

29

Web 2.0 Security in the SDLC

SDLC

30

Security / SDLC Success Factors

Make sure the PM has budgeted hours and dollars for security requirements, implementation, code review, testing and monitoring.

If its not in the PMs level-of-effort, it will not get done. Finds many more problems than scanning or black-box testing Side benefit: Developers gain training

Include code review with the security architect and developers

Extremely cost-effective

Do not rely on after-the-fact discovery of vulnerabilities

31

Initiation: Governance Requirements

Need

governance to say how new content will be posted to the site Standard for classifying web site type or content Obvious example is inaccurate Wiki entries Protect against internal-confidential information being shared on your public site

32

Other Governance Questions

Where to store application secrets, e.g. connection strings Application server configuration file, protected OS filesystem, system registry, manual entry at boot (lose auto-restart) Example: Requirement to encrypt properties file, with custom loader? Requirement: Check XML external entity reference (XML property) Requirement: Restrict redirects

33

Requirements Analysis Deliverables

Collection & Analysis Test Plan with security tests Release plan with control verification Initial System Security Plan Risk Assessment Updates

Requirements

34

Sample Requirements: Server-side Validation

Web applications consume XML blocks (such as SOAP messages) coming from AJAX clients Risk: Attacker will send repeated payloads, malformed XML blocks, for DoS Requirement: XML parsing on the server side Requirement: Check XML external entity reference (XML property) Requirement: Malware protection for file uploads Requirement: Restrict redirects

Include these in your test plan, regression testing, on-going controls testing Be able to tell the PM and developers why a requirement is there Non-traceable requirements tend to disappear from the final product Especially non-functional requirements like security

Maintain traceability

35

Testing
Usual

quasi-penetration testing, e.g. with metasploit or nmap Discover hosts, check for services that are listening Try to gain access Find high-risk modules Find / exploit known vulnerabilities Hit client-side vulnerabilities Try to alter application behavior, manipulate sessions, try to expose, alter or delete data, try to take control
36

Testing
Walk

through individual controls

Be clear on the role of each compensating control

Test

web services routing, interception & tampering at intermediate nodes

Does the application need encryption? Will encryption break anything?

37

Sample Tests

Check for XPATH injection in SOAP messages

~= SQL injection Can bypass authentication Input validation before passing values to an XPATH statement Need SOAP parameter input validation Binary runs from clients machine and shares browser's session Can bypass authentication, if the binary is tampered with Check binary signature

Check for SOAP parameter manipulation

RIA (Rich Internet Applications)

38

Operations & Maintenance

Re-test

at periodic intervals

If you have external services, their operations are probably changing, and they are probably not notifying you.

Periodic

scanning Establish monitoring

Review your logs!

39

Conclusion
Web

2.0 is powerful and very useful As regular Web 2.0 user, you need to be careful As Web 2.0 developer
Source Code Review Security Testing

Q/A Thank You

Ken Huang, CISSP ken.huang@cgifederal.com Jim Hewitt, CISSP PMP james.hewitt@cgifederal.com