Web20 Security Final

8/6/2019 Web20 Security Final

http://slidepdf.com/reader/full/web20-security-final 1/41



Agenda

Web 2.0 Defined

Top Web 2.0 security vulnerabilities

Secure development of Web 2.0 applications

2



What is Web 2.0?

SocialWebsites: LinkedIn, Facebook, Twitter

Sharing: blog, wiki, forum, and user groups

Mashup: GoogleMashup Editor, GoogleMaps API,

Yahoo Pipes,Microsoft Popfly, Yahoo!Widgets andGoogle Gadgets

User Generated

3



Examples of Web 2.0 Sites

Blog

Photo sharing

Wiki

ForumsFacebook

4



Technologies used in Web 2.0

AJAX: Asynchronous JavaScript and XML.

JSON: JavaScript Object Notation

REST: Representational State Transfer

SOAP: Simple Object Access ProtocolRSS: Really Simple Syndication

Flash: Adobe Flasher video player

5



_experience the commitment TM



Countermeasures as a Web 2.0 User

Use strong passwords

Dont put your birthday or other personal information onFacebook 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 toanswer.



XSS: Cross Site Scripting



XSS: May 11, 2010 on Yelp

11



XSS in WhiteHouse.gov ± May 10, 2010



Cross Site Request For gery (XSRF)

13



Example of XSRF

14



Countermeasures as a Web developer

Dont trust any user input

Best: Use white list approach

Blacklist approach

Mixed approachEscape and encode input

SessionManagement



18

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

Information Leakage in Social Websites



Facebook Privacy Settings

23



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



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

30

SDLC



Security / SDLC Success Factors

� Make sure the PM has budgeted hours and dollars for securityrequirements, implementation, code review, testing andmonitoring.

� If it¶s not in the PM¶s level-of-effort, it will not get done.

�Include code review with the security architect and developers

� Finds many more problems than scanning or black-box testing

� Side benefit: Developers gain training

� 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 beposted to the site

� Standard for classifying web site type or content

�Obvious example is inaccurate Wiki entries

� Protect against internal-confidential informationbeing shared on your public site

32



Other Governance Questions

33

� 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



Requirements Analysis Deliverables

�Requirements Collection & Analysis

�Test Plan with security tests

�Release plan with control verification

� Initial System Security Plan

�Risk Assessment Updates

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

� Maintain traceability ±

� 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

35



Testing

� Usual quasi-penetration testing, e.g. with metasploitor 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, manipulatesessions, try to expose, alter or delete data, try totake control

36



Testing

� Walk through individual controls� Be clear on the role of each compensating control

� Test web services routing, interception & tamperingat 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

� Check for SOAP parameter manipulation� Need SOAP parameter input validation

� RIA (Rich Internet Applications)

� Binary runs from client¶s machine and shares browser's session

� Can bypass authentication, if the binary is tampered with

� Check binary signature

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 [email protected]

Jim Hewitt, CISSP PMP [email protected]

Web20 Security Final

Documents

Transcript of Web20 Security Final