Junaid Loonat

SensePost 2010

beta

Web 2.0Security Woes

Agenda Who are we are? What is this talk about? Web Application Security & Web 2.0 What changed? What stayed the same? What can be done? Questions

Who are we? SensePost

Formed in 2001 Security assessment services to finance,

industrial, mining, telecoms Written a few papers.. Spoken at a number of conferences (BlackHat,

Defcon, …) Contributed to a handful of books Done some Training

www.sensepost.com/blog

What is this talk about? Not …

About the relationship between Security and Compliance Btw, it’s a love / hate marriage … just like the rest of us

A Developer-Bashing Campaign Developers are good at making something magical, from chains of

code Promoting internet-less-ness (since the internet is too

dangerous) Some SPers are more paranoid than others though

A technical presentation So please don’t run away

Is: Clear up the misconception that Web 2.0 is securer Educate on how to limit your risk when deploying a web

application

Web Application Security Why target?

Traditional perimeter security had matured Websites (and web services) are commonly used

to share information … Always on Easy target

Web 2.0 Better user experience

More interaction More functionality

But what about security? Things got bad!

… REALLY bad!

What changed? … Likely Targets Likely Targets

1.0 Intruder interacts with website

therefore, the website is the target

WebsiteMaintainer

Visitors

What changed? … Likely Targets Likely Targets

2.0 Intruder still interacts with website, but Intruder can interact with other users, through the

targeted website therefore, other website users are targets as well

WebsiteMaintainer

Visitors

Normal Visitors

Contributing Visitors

The complete compromise of the hosting environment is not a prerequisite to the complete

compromise of client systems.

What changed? … Page Interaction Page Interaction

1.0 User makes request … Server replies User’s browser loads any additional page resources

defined within the server response

2.0 User makes request … Server replies User interacts with webpage,

Scripts performing their own requests to the web server Use web services for lookups

Scripts have their own lifetime

What changed? … Page Interaction Example: CAPTCHA

UsernamePassword

junaid

**********

Code

alotocibil

1.0 Validation

performed upon submission

2.0 Validation can be

performed during field population

Login

What changed? … Building Blocks Components

Pages can be comprised of: Resources (images, stylesheets) Scripts (JavaScript, Flash) Web services

Authentication and Authorisation, the Authz, has to be enforced across all components Otherwise there is a loophole to access sensitive data

What changed? … Building Blocks Example: Uniform Enforcement of the Authz

getAllFriendMessages(“junaid”)

Access Denied

WebsiteAttacker

getMessagesByFriend(“junaid”, “ian”)

Msg #1 … Msg #n

Similar issue identified on a client’s system whichwas built on Drupal

Securely developed frameworks do not always lead to securely developed

applications

(But they do provide a good foundation)

What changed? … Building Blocks Components

Pages can be comprised of: Resources (images, stylesheets) Scripts (JavaScript, Flash) Web services

Authentication has to be enforced across all components Otherwise there is a loophole to access sensitive data

Application Complexity Some development teams #FAIL to recognise

where trust boundaries are located

What changed? … Building Blocks Example: Error Message Information Exposure

UsernamePassword

junaid

**********

Login

The developers failed to recognise that this particular web service fell outside one of the trust boundaries

Authentication Failed

ian

Authentication Failed

<auth><result>Incorrect Password</result></auth>

<auth><result>Account Locked</result></auth>

What stayed the same? Fact remains …

Many didn’t get security right with Web 1.0 applications

Needless to say, many still don’t get security right with Web 2.0 applications

Web 2.0 has allowed for new variations of older attacks You may have fixed the known issues, but others

could still exist

What stayed the same? Example: Vanilla Cross-site Scripting

What is your name?

junaid SubmitAttacker

…<p>Hello junaid!</p>…

Website

What is your name?

<script>alert(‘junaid’)</script>

SubmitAttacker

…<p>Hello <script>alert(‘junaid’)</script>!</p>…

Website

What stayed the same? Example: Cross-site Scripting (into JavaScript)

What is your name?

<script>alert(‘junaid’)</script>

SubmitAttacker …

<script>var name=‘scriptalert(’junaid’)/script’;Document.write(name);</script>…

Website

What is your name?

Blah’;alert(‘junaid’);var tmp=‘

SubmitAttacker …

<script>var name=‘Blah’;alert(’junaid’);var tmp=‘’;Document.write(name);</script>…

Website

What stayed the same? Fact remains …

Many didn’t get security right with Web 1.0 applications Needless to say, many still don’t get security right with Web

2.0 applications

Web 2.0 has allowed for new variations of older attacks You may have fixed the known issues, but others could still

exist

Hidden functionality … never remains a secret! In Web 1.0, we searched for files hidden within the web

directory In Web 2.0, we investigate web services in order to locate

hidden methods

What stayed the same? Example: Hidden web service methods

getFile(“myfile.txt”)

Web ServiceAttacker

getFile(“../../../../boot.ini”)

… contents of myfile.txt …

Access Denied

getFileByPath(“c:\boot.ini”)

… contents of boot.ini …

Validation routines recognised that the requested file existed outside of the uploads directory

Though undocumented, the getFileByPath() method existed and could be used to retrieve any file

What can be done? As a Development House:

Security Education / Training Industry has failed to teach this during a programmer’s early

years (High School and University) Developers need to understand where things usually go wrong

Defensive Coding Never trust user input Make fewer assumptions

Don’t rely on exceptions to occur whenever the application is not used correctly

Source code reviews Correct your Systems Development Life Cycle

Security audits are not to be conducted prior to deployment Involve security officers to observe the project as it progresses

What can be done? As a Customer:

You get what you pay for Smaller budget » less development time » pressured developers

» possibly more bugs

Make security a requirement Like most things in life … you won’t get it unless you ask for it

Use experienced Development Houses If the team has had one of their applications pentested before,

then they are likely to understand what gets exploited If they make use of a common (custom) framework between all

their projects, then security changes are commonly applied to all versions

Security is a journey, not a destination.

(So remember to buckle up, and enjoy the ride)

Questions ???

junaid@sensepost.comwww.sensepost.com/blog