Secure Programming Lecture 12: WebApplication Security III

David Aspinall

6th March 2014

Outline

Overview

Recent failures

More on authorization

Redirects

Sensitive data

Cross-site Request Forgery (CSRF)

Deployment

Summary

Outline

Overview

Recent failures

More on authorization

Redirects

Sensitive data

Cross-site Request Forgery (CSRF)

Deployment

Summary

OWASP Top 10 list 2013

É A1 Injection ØÉ A2 Broken Authentication & Session Management ØÉ A3 Cross-Site Scripting (XSS) ØÉ A4 Insecure Direct Object References ØÉ A5 Security MisconfigurationÉ A6 Sensitive Data ExposureÉ A7 Missing Function Level Access ControlÉ A8 Cross-Site Request Forgery (CSRF)É A9 Using Components with Known VulnerabilitiesÉ A10 Unvalidated Redirects and Forwards

Outline

Overview

Recent failures

More on authorization

Redirects

Sensitive data

Cross-site Request Forgery (CSRF)

Deployment

Summary

Starbucks iPhone payments (until Jan 2014)

Daniel Woods pointed out that Starbucks iPhone app storedpasswords in the clear. After wider publicity they eventually fixed it.

SOHO Pharming (Jan 2014)

See InfoSecurity article

Outline

Overview

Recent failures

More on authorization

Redirects

Sensitive data

Cross-site Request Forgery (CSRF)

Deployment

Summary

Missing function-level access control (A7)

This is OWASP’s term for not authorizing properly theoperations, i.e., functions, that the web appimplements.

This is separate from handling authorization at the levelof

É pages (apps might have several functions per page)É external objects

Common mistake:

É Hiding navigation links to “unauthorized” sectionsÉ . . . assuming (wrongly) this prevents non-authorized

users visiting themÉ e.g., no AdminPage link if not logged in as an admin

XKCD #1200

OWASP authorization advice

É Have well-specified policyÉ if non-trivial, separate it from code

É Manage authorization in a separate moduleÉ have a single route through codeÉ can trace to make sure authorization happens

É Make authorization checks for each functionÉ Use deny-by-default policy

Outline

Overview

Recent failures

More on authorization

Redirects

Sensitive data

Cross-site Request Forgery (CSRF)

Deployment

Summary

Leaving HP

Unvalidated redirects and forwards (A10)

Web apps often allow redirections which

É send users off-site with a polite messageÉ reroute them immediately

http://www.example.com/redirect.jsp?url=www.disney.com

or forwards which

É redirect internally to different parts of the same site

http://www.example.com/login.jsp?fwd=admin.jsp

Question. What’s the security risk here?

Outline

Overview

Recent failures

More on authorization

Redirects

Sensitive data

Cross-site Request Forgery (CSRF)

Deployment

Summary

Information leakage

Reminder from first security course:

Confidentiality is defined as the

unauthorised learning of information

Presumes notions of

É authorisation likely based on an . . .É access control policy likely based on . . .É authentication.

Information leakage

Information can be learned in a variety of ways:

É direct exposureÉ display on a public web pageÉ may be inadvertent on part of user

É indirect/inferred exposureÉ programming mistakes showing wrong infoÉ display of consequences of info

É leakage through side-channel attacksÉ e.g., timing attacks

É (via) offline mechanismsÉ social engineering to get passwords, etc

The Privacy Crisis

Several security researchers and technologycommentators have said:

"Privacy is dead, get over it!"

We can’t stop people intentionally sharing personalinformation, but it is our job to ensure:

É good programming: don’t leak data accidentlyÉ good security design: don’t force users to leak dataÉ good UX/UI: so users know what they’re doing

Of course there may be competing incentives to exposepersonal data (Q. for example?).

But it is better that data handling practices are definedand explained clearly in privacy policies for end users.

Example: search data

Google

É may save your web search history for ever!É gives users the option to turn this off; then searches

are partially “anonymized” after 18 months.

Example: voice controlApple’s Siri keeps voice data for up to two years:

Here’s what happens. Whenever you speak intoApple’s voice activated personal digital assistant, itships it off to Apple’s data farm for analysis.Apple generates a random number to represent theuser and it associates the voice files with thatnumber. This number — not your Apple user ID oremail address — represents you as far as Siri’sback-end voice analysis system is concerned.Once the voice recording is six months old, Apple“disassociates” your user number from the clip,deleting the number from the voice file. But it keepsthese disassociated files for up to 18 more monthsfor testing and product improvement purposes.

Wired’s article from 2013, attempting to clarify Apple’s behaviour.

Example: an amazing mind reader

See the video campaign by Safe Internet Banking inBelgium.

Exercise. What has this got to do with banking? Andwhy should it have anything to do with it?

Basic strategy for sensitive data handling

0. Define your policy, devise requirements1. Label the data at least informally2. Follow the data through the app and check

Check questions for data flow:

É is the data stored as plain text long term(e.g. backups)?

É is the data transmitted as plain text?É are encryption algorithms strong enough?É are browser security directives/headers set

appropriately?

OWASP advice for sensitive data:

1. Don’t store unnecessarily2. Encrypt appropriately (e.g., large keys if long term)3. Use known strong encryption algorithms4. Manage passwords properly5. Disable auto-completion on forms, disable caching

Regulation

If you are manipulating or storing sensitive user datayou may have (legal) responsibilities for managing itproperly. For example:

É DPA UK Data Protection ActÉ organisations must register and data must be kept

“safe and secure”. Prosecutions have taken place.

É PCI Payment Card Industry Data Security StandardÉ requirements for anyone who processes card dataÉ larger merchants are audited

É In the US: HIPPA (Healthcare providers)

Given the scale and frequency of data lossage,regulation/enforcement is likely to increase. (Expectsecurity companies to push for and profit from this.)

Outline

Overview

Recent failures

More on authorization

Redirects

Sensitive data

Cross-site Request Forgery (CSRF)

Deployment

Summary

Cross Site Request Forgery (CSRF) (A8)

É Exploit browser’s trust relationship with a web siteÉ local intranet web site (home router admin, . . . )É banking or email site user is logged intoÉ browser is authorized to connect here

É Attacker triggers malicious actionÉ get user to open malicious linkÉ browser undertakes action on target site

Question. How does CSRF differ from XSS?

CSRF in pictures

CSRF in code

Alice is logged in to the (hypothetical) GeeMail webmail system.

She sends an email with this form:

<formaction="http://geemail.com/send_email.htm"method="GET">Recipient’s Email address: <inputtype="text" name="to">Subject: <input type="text" name="subject">Message: <textarea name="msg"></textarea><input type="submit" value="Send Email"></form>

Example GET request

Which sends a request like this:

http://geemail.com/send_email.htm?to=bob%40example.com&subject=hello&msg=What%27s+the+status+of+that+proposal%3F

Attacker’s cross-site request

Now Mallory just needs Alice to visit a site which loadsan image link, e.g., by putting a fake image on his ownblog

<img src="http://geemail.com/send_email.htm?to=charlie@geemail.com&subject=Hi&msg=My+email+address+has+been+stolen">

and Alice’s browser will send an Email!

Confused Deputy problem

CSRF is a case of the “confused deputy” problem.Problem motivates use of capabilities.

See The Confused Deputy by Norm Hardy, ACM SIGOPS OperatingSystems Review, 1988. Picture credit: FP7 project Serscis

Avoiding CSRF problems

In general: tricky. Need some way to assure the servercode that the request has come from intended place.

É Referer header not tamper proof, may be absentÉ Session ID cookie sent based on destinationÉ The Same Origin Policy restricts client-side code,

not what requests are sent to server

Best strategy: use a good framework that providesbuilt-in protection.

But how do they work?

É Don’t use GET for any (sensitive) state changeÉ basic starting point

É Use a “double cookie” trick, repeated in POSTÉ set a secure secret session ID in a cookieÉ submit it in cookie and hidden field on formÉ server-side, check fields identicalÉ this works but has drawback (Q. what?)

É Use a special CSRF token in POSTÉ secure random number (challenge) for each loginÉ send this with POST and check server-sideÉ save state: generate using hmac from session ID

Future: idea for an Origin header in POST.

See Robust defenses for cross-site request forgery, Barth et al, ACMCCS 2008.

Outline

Overview

Recent failures

More on authorization

Redirects

Sensitive data

Cross-site Request Forgery (CSRF)

Deployment

Summary

Misconfiguration (A5)

The whole web app stack must be secured (Q. Why?)

É Make sure up to date wrt security patchesÉ OS, Web/App Server, DBMS, app framework, libs. . .

É Disable unnecessary featuresÉ Default accounts, demo pages, debug interfaces

É Use minimum privilege settingsÉ Security settings for frameworks and libraries

É Ensure error handling doesn’t expose infoÉ Have a repeatable security config process

É An app-specific checklist to work throughÉ Proactive deployment of updatesÉ Uniform configuration for devel, QA, deployment

Inherited vulnerabilities (A9)

Big cause of real-life vulnerabilities:

patch was available but not installed

É Need to stay up-to-dateÉ Can be harder than might be hoped

É no unique clearing house (but CVE, NVD v.~good)É unsatisfiable compatibility dependencies

É Future: expect to see more automated tools

Outline

Overview

Recent failures

More on authorization

Redirects

Sensitive data

Cross-site Request Forgery (CSRF)

Deployment

Summary

Review questions

Authorization

É How might you design a web based adminfront-end to a database server, supposing that theserver provides a collection of databases and itsown notion of user and authorization?

Redirection

É What is an open redirect in a web application andwhy is it undesirable?

Handling sensitive data

É Describe three ways that a web applicationprogramming flaw might result in stored privateuser data being leaked.

CSRF

É Draw a picture showing how a CSRF attack mightwork against an online banking user. What mightan attacker be able to do?

É What does a defence mechanism against CSRFneed to be able to do?

Deployment

É Give three recommendations for securing thedeployment environment (server, database,application framework) for a web app.

References

This lecture contained material from:

É the OWASP Top 10É The Tangled Web: a Guide to Securing Modern Web

Applications by Michal Zalewski, No Starch Press,2012.

as well as papers and other sources cited.