Web App Security Techniques for Developers

Web Application Security
Guillermo Pérez
bisho@tuenti.com
BE arch & Security Lead Eng.

bcndevcon 2011

Things to deal with...
in web app security

Web App security
● Anonymous attackers
● Worldwide access
● Shared environment for all users
● Easy distribution, profitable
● On top of all other components security:
○ Network security
○ OS security
○ Server software security
○ Social Engineering
○ Even more! browsers, plugins, virus, user computer
security, shared computers, open wifis...

Web App security

Humans (developers) are the bigger risk

Give tools, frameworks & policies so no
developer has to ever think how to secure up
things. Should be clear and the easiest path.

But there is no perfect security...

Top 10 security issues in webapps
From OWASP (risks != frequency)
1. Injection
2. XSS
3. Broken auth, session management
4. Insecure direct object references
5. CSRF
6. Security misconfiguration
7. Failure to restrict URL access
8. Unvalidated redirects
9. Insecure crypto storage
10. Insufficient transport layer protection

1. Injection
2. XSS
5. CSRF

1. Injection flaws

Trick services to execute unintended
commands to gain control or access
unauthorized data.

● Several types:
○ SQL
○ OS execution
○ LDAP
○ XPath
○ NoSQL
○ uploads

1. Injection flaws
● Explotability: EASY
● Prevalence: COMMON
● Detectability: AVERAGE
● Impact: SEVERE
● Prevention:
○ Keep untrusted data separate from commands
● How:
○ Use safe, parametrized apis vs writting code to be
executed by interpreter.
○ Escape special chars depending on interpreter.
○ Data cast, whitelist input validation.

1. Injection flaws: SQL
● http://example.com/?id=' or '1'='1
● Explicit cast, escaping IN-PLACE
○ mysqli_escape_string()
○ ...
● Use prepared statements
○ Provides data separation
○ Client-side implementations (PDO)
○ SELECT * FROM table where id=?
● Use safe apis for query generation
○ $mysqlService->select($table, $pk, $fields,
$where...)
● Safe ORM framework
○ $storage->read($keys);

1. Injection flaws: OS

● Don't use OS execution :)
● Escape
○ escapeshellarg

1. Injection flaws: uploads

● Don't put them on public folder
● Don't use user-provided data for names
● Whitelist extensions
● Validate content
● Store separately from app (DB, separate
servers)
● Ensure write permissions are the minimum
possible

2. XSS

Trick services to return browser-executable
code to user/s.

● Several classifications:
○ Breaking context vs sub-context
○ Persistant vs non-persistent
○ Traditional vs DOM

2. XSS
● Explotability: AVERAGE
● Prevalence: WIDESPREAD
● Detectability: EASY
● Impact: MODERATE
● Prevention:
○ Escape untrusted data depending on context
○ HTTP-Only Cookie mitigation is useless
● How:
○ Escape everything (even safe vars)
○ Escape in TEMPLATES (context aware)
○ Other (URL params) in specialized safe apis
○ Unit test

2. XSS: Classification by context

● Breaking context:
○ <a href="?id<?=$_GET['id']?>">
○ "<script> ...
○ Easy to detect & test
■ Unit-test templates with all injections for all vars
and validate html
● Non breaking context:
○ <a href="<?=$_GET['url']?>">
○ javascript: ...
○ HARD TO DETECT

2. XSS: Classification by persistance
● Persistant
○ Data gets stored in DB
○ Users will be hit by regular navigation
○ Easier to test (templates)
● Non persistant
○ A request with some params returns XSS
○ Users need to be trick to navigate into the malicious
link
○ More frequent (No results for 'blah')
○ Somewhat harder to test (cover error messages,
non-template based responses)

2. XSS: Classification by mode

● Traditional
○ Just by exploiting browser parsing
○ Easy to test
● DOM
○ Cheating on JS
■ data from server injected in DOM
● Use innerText
● Do not compose html in JS
■ parsing data from uri, forms as 'safe'
○ Pretty hard to test. Avoid missuse, provide safe apis.

2. XSS

@tuenti
● Escape on templates
● Escape everything, even what doesn't need
to be escaped:
○ <?=View::escape_unsafe($html)?>
● Link generation framework
● Tests for templates, controllers

2. XSS: HTML
● Never put untrusted data in:
○ <script> contents
○ HTML comments
○ tag/attribute names
○ <style> contents
● Contexts: Content, attributes, url params,
urls, js...
● Rich formating
○ Use alternative markup lang
■ Markdown
■ Textile
○ Filter HTML (white listing, carefull!!!)

2. XSS: JS

● Encode with xNNN (" might break HTML
that is parsed before)
● Prefer reading values from dom
● URL pieces are not safe
● Beware of double context: setInterval('...'),
eval()

2. XSS: JSON
● Easy to escape (single context)
● Can put the load on the browser (harder to
test)
● Avoid mixing contexts (json on html, or json
with/for html)
● Eval json as js can trigger js execution
○ Safe, full json encoding in server (never use half-
baked json templates!!!)
○ Use the slow json-parse.js vs json.js regexp
validation
● Be aware of context. content-type!

3. Auth & Session

Attack authentication and sessions to gain
control over an account.

● Passwords
● Session issues

3. Auth & Session

● Impact: SEVERE
● Prevention:
○ SSL, good session handling, detect auth brute force,
avoid plain text passwords, strong password
recovery, user sessions control (logout, history,
close all), detect anomalous login patterns...

3. Auth & Session
● Passwords
○ Use SSL or digest auth
○ Enforce good passwords, rotation
○ Store passwords securely (constant time salted
hashes)
○ fight phising (easy URL, educate users)
● Authentication
○ Don't make distintions between bad login / password
○ Reset to hide real logins, time-limited tokens, old
password invalidate resets
○ Detect brute force, lock accounts
○ Watch misconfigurations
○ Specially on admin, secondary platforms

3. Auth & Session

● Sessions
○ Random Ids, >= 128 bit
○ Use SSL
○ Use secure=yes, httponly for cookies
○ No session fixation
○ No session ids in URLs
○ Change session id on priviledge scalation or switch
between http->https
○ Expiration
○ Offer logout, history, close all
○ Do not send cookies to CDNs, non-principal sites

4. Direct object references

Apps usually map backend objects to URLs.

An attacker might bypass privacy and
authentication by accessing directly to
resources if don't do the appropiate checks.

● Trusted params
● Images


● Prevention:
○ Properly check privacy on all objects
○ Good policy on where to put the privacy check
○ Do not trust params. Sign params is an option
○ Hide real db keys (show pos X in search Y, /me)
○ Make urls hard to guess


Sounds stupid...
...but happens!


● Never check privacy on controllers
● Never check privacy on storage layer
● Privacy in backend api methods
○ With entry point documentation
○ Clear responsibility for privacy!
○ Most of the time implicit with good api design
○ Good performance
○ Easy to use privacy framework


● Documentation
/*
* @epoint-changes-state YES
* @epoint-privacy-control IMPLICIT
* - Only deletes current user tag if exists.
* @epoint-summary Deletes the current user's tag on a photo
*...
*/
public function deleteMyTag($photoKey) {
$userId = CurrentUser::getId();
...


● Privacy framework api
○ TPrivacy::hasAnyOf / hasAllOf
○ + Privacy providers

if (TPrivacy::hasAnyOf(
CurrentUser::getId() == $photoOwner,
array('TagApi', TagApi::IS_TAGGED, $photoKey),
array('...
...
)) {

5. CSRF

Cross site request forgery [CSFR in tuenti :)]
Trick a authenticated user to submit requests to
a service and do actions without consent. The
browser will send the cookies and the request
might look legit.

● Image tags (get)
● Forms (post)
● ...

5. CSRF

● Prevalence: WIDESPREAD
● Prevention:
○ Require a non-predictable token param on all
actions that modify state
○ Use POST for all actions that modify state
○ Use custom header in ajax requests
○ Check Origin header when available!!!

5. CSRF

@tuenti:
● Before was check when using a post param
○ Default values caused us issues
● Now explicit annotation on controllers
○ @ChangesState
● Evangelize developers


Missing security updates, open proxies, open
ports, default accounts, directory listing,
forgotten hardening...


● Prevention:
○ Develop install & configuration procedures
○ Document services and subscribe to updates
○ Hide services versions when possible
○ Separate components to minimize risks


@tuenti:
● we are big >1k servers
○ + possibilities for some issue
● But...
○ We use config management (pupet)
○ Good deployment procedures, documentation
○ Very isolated services
○ Few generic web components
○ Good systems team

7. URL access

Attacker guesses URLs that lead to
functionality, information.

7. URL access

● Prevalence: UNCOMMON
● Prevention:
○ Deny by default
○ Deploy by selection

7. URL access

@tuenti
● Good deploy system
● Splited environments for production and dev
● Most non-public services restricted to vpn +
centralized auth


Use a service redirect to trick users into clicking
on a link (belongs to valid service) and achieve
more effective phising/virus
downloads/revenue.


● Prevention:
○ Don't expose destination URL as param, use
references to a white list
○ Ensure end URLs are safe (Safe search, user
reporting tools...)


Some data is sensible enought to require being
stored encripted/hashed, to protect it from
being stolen.

Unsalted hashes might be exploitable, backups
might contain keys or cleartext, services might
expose decrypt mecanisms, internal attacks
might have access to keys.


● Explotability: DIFFICULT
● Detectability: DIFFICULT
● Impact: SEVERE
● Prevention:
○ Keep backups encripted, don't store keys on same
place.
○ Use salted hashes and constant time hashes
○ Ensure keys are protected
○ Don't offer full info (credit card XXXX 1234)

10. Transport layer protection

An attacker might sniff traffic of your users to
steal sessions to retrieve data, do spam...

10. Transport layer protection

● Explotability: DIFFICULT
● Prevention:
○ Ensure to use SSL on all requests & resources
loaded.
○ Change session ids when switching to https.
○ If optional, try to detect shared IPs and auto-enable
on those.

1. Injection
2. XSS
5. CSRF
11. Extras

11. Extras: Cross domain data leak

Ajax is changing the web apps, with js-rich
clients that request data.
Beware of exposing JS / JSON user data
through GET requests without CSRF
tokens/headers! <script> tag is not Cross
Domain safe!
● Require custom header (needs
XMLhttpRequest) keep using GET
● Check origin header

11. Extras: Clickjacking

Trick users to click/copy content on your page
(by-passing CSRF) by using a hidden frame
● Use Frame-options
● Some anti-frame JS (hard)
○ top.location might not be accesible, cause JS error
○ redirections might be cancelled
○ Best (not pretty):
blank page with link target _blank, if top.
location == self.location, add content

11. Extras: Unicode

● Filter special unicode that can break design
● UTF encoding might bypass your XSS-filters
● UTF url encoding might bypass directory
checks...
● NULL code %00 might bypass suffixes

11. Extras: HTTP/Mail Headers

● Are subject to CR/LF injection, leading to
○ XSS
○ Spam
○ redirection
○ ...
● Use safe api

11. Extras: People

● People is always the weakest link
● Phising
○ Educate
○ Good urls
○ Design
○ Referer analysis
○ React
● Self-inflicted JS injection
○ Educate
○ Filter content, be aware of surges

No input validation?
Minimize malformed data, make it match
business needs.
NOT as primary method to avoid XSS,
injection...

● Rules:
○ SERVER SIDE
○ Apply to all (form, url params, cookies, http headers)
○ Define whitelists of valid chars
○ Define length
○ Business on top of that

No input validation?

● Even thought, tuenti has a good validation
system:
○ Based on annotations on controllers.
○ At data layer (storage definition)
● Makes exploits harder
● Good practice, clean code
● Explicit args in controllers

Logging, stats, counters

● Very important for security
● Stats:
○ Detect issues, patterns to take measures.
● Logs
○ Analize issues.
● Counters
○ Detect & react to malicious activity

Error handling

● Sanitize error messages, use same
templating system
● Do not provide information to users
● Control debug mode
● Dangers:
○ Log review tools (XSS)
○ As payload upload mecanism

Community
● Take care of community!
○ Thank security researchers
○ Reply fast
○ <24h fix policy
○ Tipically <2h!
○ Hall of FAME!!!
● How to report
○ Standard box security@tuenti.com + dns entries
○ Regular user support
○ Researchers know us

Browser XSS protections

● Reflexion XSS protection
○ Different implementations IE8, chrome
○ Adds issues, new problems
○ Non perfect, might improve?

Client side templates

● Data only requests are easier to escape
● It's harder to inject data into client-side
templates (only persistent XSS)
● Templates might work in DOM mode
● SLOW in non recent browsers

Better JS

● More secure mashups
○ Google Caja...
● More enterprise JS
○ Dart, GWT, Closure, CoffeeScript

Plugins ... Apis ... Browsers

● Flash plugin will die!

● But new HTML5 apis will bring more issues

● Browsers extensions nightmare

Avoid cookies

Using XMLHttpRequest with sid as param, from
rich JS apps. Destination domain that does not
have cookies.

● Decreases attack vectors on:
○ CSRF
○ Click jacking

SSL improvements

● HSTS
○ Force SSL
○ Certificate pinning
● False start
○ -30% handshake latency

Content Security Policy (Mozilla)
● Restricts a lot of attacking vectors
○ Forbids inline javascript
○ Forbids dynamic js code: eval, setTimeout(<string>)
○ Restricts inline data source (can be reverted for
images for example)
○ Whitelist sources for each type of content (js, css,
images, ajax...)
○ Configures frame permissions better
● Hard to implement in complex sites
○ twitter mobile is using it
○ Reports issues (to detect attacks, debug/testing
phase)

?
bisho@tuenti.com

We are hiring!
http://jobs.tuenti.com

Web App Security Techniques for Developers

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Web App Security Techniques for Developers

Ähnlich wie Web App Security Techniques for Developers (20)

Mehr von Tuenti

Mehr von Tuenti (8)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Web App Security Techniques for Developers