Web Application Security                    Guillermo Pérez                  bisho@tuenti.com            BE arch & Securit...
Things to deal with...     in web app security
Web App security●   Anonymous attackers●   Worldwide access●   Shared environment for all users●   Easy distribution, prof...
How to achieve it?
Web App security  Humans (developers) are the bigger risk   Give tools, frameworks & policies so nodeveloper has to ever t...
Top risks?
Top 10 security issues in webappsFrom OWASP (risks != frequency)  1. Injection  2. XSS  3. Broken auth, session management...
Top 10 security issues in webapps 1.   Injection 2.   XSS 3.   Broken auth, session management 4.   Insecure direct object...
1. Injection flawsTrick services to execute unintendedcommands to gain control or accessunauthorized data.● Several types:...
1. Injection flaws●   Explotability: EASY●   Prevalence: COMMON●   Detectability: AVERAGE●   Impact: SEVERE● Prevention:  ...
1. Injection flaws: SQL● http://example.com/?id= or 1=1● Explicit cast, escaping IN-PLACE  ○ mysqli_escape_string()  ○ ......
1. Injection flaws: OS● Dont use OS execution :)● Escape  ○ escapeshellarg
1. Injection flaws: uploads● Dont put them on public folder● Dont use user-provided data for names● Whitelist extensions● ...
Top 10 security issues in webapps 1.   Injection 2.   XSS 3.   Broken auth, session management 4.   Insecure direct object...
2. XSSTrick services to return browser-executablecode to user/s.● Several classifications:   ○ Breaking context vs sub-con...
2. XSS●   Explotability: AVERAGE●   Prevalence: WIDESPREAD●   Detectability: EASY●   Impact: MODERATE● Prevention:    ○ Es...
2. XSS: Classification by context● Breaking context:  ○ <a href="?id<?=$_GET[id]?>">  ○ "<script> ...  ○ Easy to detect & ...
2. XSS: Classification by persistance● Persistant  ○ Data gets stored in DB  ○ Users will be hit by regular navigation  ○ ...
2. XSS: Classification by mode● Traditional  ○ Just by exploiting browser parsing  ○ Easy to test● DOM  ○ Cheating on JS  ...
2. XSS@tuenti● Escape on templates● Escape everything, even what doesnt need  to be escaped:    ○ <?=View::escape_unsafe($...
2. XSS: HTML● Never put untrusted data in:  ○ <script> contents  ○ HTML comments  ○ tag/attribute names  ○ <style> content...
2. XSS: JS● Encode with xNNN (" might break HTML  that is parsed before)● Prefer reading values from dom● URL pieces are n...
2. XSS: JSON● Easy to escape (single context)● Can put the load on the browser (harder to  test)● Avoid mixing contexts (j...
Top 10 security issues in webapps 1.   Injection 2.   XSS 3.   Broken auth, session management 4.   Insecure direct object...
3. Auth & SessionAttack authentication and sessions to gaincontrol over an account.● Passwords● Session issues
3. Auth & Session●   Explotability: AVERAGE●   Prevalence: COMMON●   Detectability: AVERAGE●   Impact: SEVERE● Prevention:...
3. Auth & Session● Passwords    ○ Use SSL or digest auth    ○ Enforce good passwords, rotation    ○ Store passwords secure...
3. Auth & Session● Sessions  ○ Random Ids, >= 128 bit  ○ Use SSL  ○ Use secure=yes, httponly for cookies  ○ No session fix...
Top 10 security issues in webapps 1.   Injection 2.   XSS 3.   Broken auth, session management 4.   Insecure direct object...
4. Direct object referencesApps usually map backend objects to URLs.An attacker might bypass privacy andauthentication by ...
4. Direct object references●   Explotability: EASY●   Prevalence: COMMON●   Detectability: EASY●   Impact: MODERATE● Preve...
4. Direct object referencesSounds stupid...    ...but happens!
4. Direct object references● Never check privacy on controllers● Never check privacy on storage layer● Privacy in backend ...
4. Direct object references● Documentation/* * @epoint-changes-state YES * @epoint-privacy-control IMPLICIT * - Only delet...
4. Direct object references● Privacy framework api   ○ TPrivacy::hasAnyOf / hasAllOf   ○ + Privacy providersif (TPrivacy::...
Top 10 security issues in webapps 1.   Injection 2.   XSS 3.   Broken auth, session management 4.   Insecure direct object...
5. CSRFCross site request forgery [CSFR in tuenti :)]Trick a authenticated user to submit requests toa service and do acti...
5. CSRF●   Explotability: AVERAGE●   Prevalence: WIDESPREAD●   Detectability: EASY●   Impact: MODERATE● Prevention:    ○ R...
5. CSRF@tuenti:● Before was check when using a post param  ○ Default values caused us issues● Now explicit annotation on c...
Top 10 security issues in webapps 1.   Injection 2.   XSS 3.   Broken auth, session management 4.   Insecure direct object...
6. Security misconfigurationMissing security updates, open proxies, openports, default accounts, directory listing,forgott...
6. Security misconfiguration●   Explotability: EASY●   Prevalence: COMMON●   Detectability: EASY●   Impact: MODERATE● Prev...
6. Security misconfiguration@tuenti:● we are big >1k servers    ○ + possibilities for some issue●   But...    ○   We use c...
Top 10 security issues in webapps 1.   Injection 2.   XSS 3.   Broken auth, session management 4.   Insecure direct object...
7. URL accessAttacker guesses URLs that lead tofunctionality, information.
7. URL access●   Explotability: EASY●   Prevalence: UNCOMMON●   Detectability: AVERAGE●   Impact: MODERATE● Prevention:   ...
7. URL access@tuenti● Good deploy system● Splited environments for production and dev● Most non-public services restricted...
Top 10 security issues in webapps 1.   Injection 2.   XSS 3.   Broken auth, session management 4.   Insecure direct object...
8. Unvalidated redirectsUse a service redirect to trick users into clickingon a link (belongs to valid service) and achiev...
8. Unvalidated redirects●   Explotability: AVERAGE●   Prevalence: UNCOMMON●   Detectability: EASY●   Impact: MODERATE● Pre...
Top 10 security issues in webapps 1.   Injection 2.   XSS 3.   Broken auth, session management 4.   Insecure direct object...
9. Insecure crypto storageSome data is sensible enought to require beingstored encripted/hashed, to protect it frombeing s...
9. Insecure crypto storage●   Explotability: DIFFICULT●   Prevalence: UNCOMMON●   Detectability: DIFFICULT●   Impact: SEVE...
Top 10 security issues in webapps 1.   Injection 2.   XSS 3.   Broken auth, session management 4.   Insecure direct object...
10. Transport layer protectionAn attacker might sniff traffic of your users tosteal sessions to retrieve data, do spam...
10. Transport layer protection●   Explotability: DIFFICULT●   Prevalence: COMMON●   Detectability: EASY●   Impact: MODERAT...
Top 10 security issues in webapps 1.   Injection 2.   XSS 3.   Broken auth, session management 4.   Insecure direct object...
11. Extras: Cross domain data leakAjax is changing the web apps, with js-richclients that request data.Beware of exposing ...
11. Extras: ClickjackingTrick users to click/copy content on your page(by-passing CSRF) by using a hidden frame● Use Frame...
11. Extras: Unicode● Filter special unicode that can break design● UTF encoding might bypass your XSS-filters● UTF url enc...
11. Extras: HTTP/Mail Headers● Are subject to CR/LF injection, leading to   ○   XSS   ○   Spam   ○   redirection   ○   ......
11. Extras: People● People is always the weakest link● Phising   ○   Educate   ○   Good urls   ○   Design   ○   Referer an...
No input validation?
No input validation?Minimize malformed data, make it matchbusiness needs.NOT as primary method to avoid XSS,injection...● ...
No input validation?● Even thought, tuenti has a good validation  system:  ○ Based on annotations on controllers.  ○ At da...
Other important aspects
Logging, stats, counters● Very important for security● Stats:   ○ Detect issues, patterns to take measures.● Logs  ○ Anali...
Error handling● Sanitize error messages, use same  templating system● Do not provide information to users● Control debug m...
Community● Take care of community!  ○ Thank security researchers  ○ Reply fast  ○ <24h fix policy  ○ Tipically <2h!  ○ Hal...
Web Security Future?
Browser XSS protections● Reflexion XSS protection  ○ Different implementations IE8, chrome  ○ Adds issues, new problems  ○...
Client side templates● Data only requests are easier to escape● Its harder to inject data into client-side  templates (onl...
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 nigh...
Avoid cookiesUsing XMLHttpRequest with sid as param, fromrich JS apps. Destination domain that does nothave cookies.● Decr...
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 ...
?bisho@tuenti.com                  We are hiring!          http://jobs.tuenti.com
Upcoming SlideShare
Loading in …5
×

Tuenti: Web Application Security

9,211
-1

Published on

Tuenti is an always growing web application, constantly adding services and applications, with two or more releases per week, a lot of branches per release, 100+ engineers hacking code and keeping hundreds of servers running. Dealing with security in such an environment is a tough challenge from different perspectives.

On this talk we will explain how we keep security levels high, the most common attacks and good practices that might help you make your web applications safer. Also, some insight in how security is understood across the whole company (legal, user support, engineering) will be given, as it is crucial for us to have top knotch incident response.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
9,211
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Tuenti: Web Application Security

  1. 1. Web Application Security Guillermo Pérez bisho@tuenti.com BE arch & Security Lead Eng. bcndevcon 2011
  2. 2. Things to deal with... in web app security
  3. 3. 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...
  4. 4. How to achieve it?
  5. 5. Web App security Humans (developers) are the bigger risk Give tools, frameworks & policies so nodeveloper has to ever think how to secure upthings. Should be clear and the easiest path. But there is no perfect security...
  6. 6. Top risks?
  7. 7. Top 10 security issues in webappsFrom 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
  8. 8. Top 10 security issues in webapps 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 storage10. Insufficient transport layer protection
  9. 9. 1. Injection flawsTrick services to execute unintendedcommands to gain control or accessunauthorized data.● Several types: ○ SQL ○ OS execution ○ LDAP ○ XPath ○ NoSQL ○ uploads
  10. 10. 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.
  11. 11. 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);
  12. 12. 1. Injection flaws: OS● Dont use OS execution :)● Escape ○ escapeshellarg
  13. 13. 1. Injection flaws: uploads● Dont put them on public folder● Dont use user-provided data for names● Whitelist extensions● Validate content● Store separately from app (DB, separate servers)● Ensure write permissions are the minimum possible
  14. 14. Top 10 security issues in webapps 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 storage10. Insufficient transport layer protection
  15. 15. 2. XSSTrick services to return browser-executablecode to user/s.● Several classifications: ○ Breaking context vs sub-context ○ Persistant vs non-persistent ○ Traditional vs DOM
  16. 16. 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
  17. 17. 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
  18. 18. 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)
  19. 19. 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.
  20. 20. 2. XSS@tuenti● Escape on templates● Escape everything, even what doesnt need to be escaped: ○ <?=View::escape_unsafe($html)?>● Link generation framework● Tests for templates, controllers
  21. 21. 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!!!)
  22. 22. 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()
  23. 23. 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!
  24. 24. Top 10 security issues in webapps 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 storage10. Insufficient transport layer protection
  25. 25. 3. Auth & SessionAttack authentication and sessions to gaincontrol over an account.● Passwords● Session issues
  26. 26. 3. Auth & Session● Explotability: AVERAGE● Prevalence: COMMON● Detectability: AVERAGE● 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...
  27. 27. 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 ○ Dont 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
  28. 28. 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
  29. 29. Top 10 security issues in webapps 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 storage10. Insufficient transport layer protection
  30. 30. 4. Direct object referencesApps usually map backend objects to URLs.An attacker might bypass privacy andauthentication by accessing directly toresources if dont do the appropiate checks.● Trusted params● Images
  31. 31. 4. Direct object references● Explotability: EASY● Prevalence: COMMON● Detectability: EASY● Impact: MODERATE● 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
  32. 32. 4. Direct object referencesSounds stupid... ...but happens!
  33. 33. 4. Direct object references● 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
  34. 34. 4. Direct object references● Documentation/* * @epoint-changes-state YES * @epoint-privacy-control IMPLICIT * - Only deletes current user tag if exists. * @epoint-summary Deletes the current users tag on a photo *... */public function deleteMyTag($photoKey) { $userId = CurrentUser::getId(); ...
  35. 35. 4. Direct object references● Privacy framework api ○ TPrivacy::hasAnyOf / hasAllOf ○ + Privacy providersif (TPrivacy::hasAnyOf( CurrentUser::getId() == $photoOwner, array(TagApi, TagApi::IS_TAGGED, $photoKey), array(... ... )) {
  36. 36. Top 10 security issues in webapps 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 storage10. Insufficient transport layer protection
  37. 37. 5. CSRFCross site request forgery [CSFR in tuenti :)]Trick a authenticated user to submit requests toa service and do actions without consent. Thebrowser will send the cookies and the requestmight look legit.● Image tags (get)● Forms (post)● ...
  38. 38. 5. CSRF● Explotability: AVERAGE● Prevalence: WIDESPREAD● Detectability: EASY● Impact: MODERATE● 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!!!
  39. 39. 5. CSRF@tuenti:● Before was check when using a post param ○ Default values caused us issues● Now explicit annotation on controllers ○ @ChangesState● Evangelize developers
  40. 40. Top 10 security issues in webapps 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 storage10. Insufficient transport layer protection
  41. 41. 6. Security misconfigurationMissing security updates, open proxies, openports, default accounts, directory listing,forgotten hardening...
  42. 42. 6. Security misconfiguration● Explotability: EASY● Prevalence: COMMON● Detectability: EASY● Impact: MODERATE● Prevention: ○ Develop install & configuration procedures ○ Document services and subscribe to updates ○ Hide services versions when possible ○ Separate components to minimize risks
  43. 43. 6. Security misconfiguration@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
  44. 44. Top 10 security issues in webapps 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 storage10. Insufficient transport layer protection
  45. 45. 7. URL accessAttacker guesses URLs that lead tofunctionality, information.
  46. 46. 7. URL access● Explotability: EASY● Prevalence: UNCOMMON● Detectability: AVERAGE● Impact: MODERATE● Prevention: ○ Deny by default ○ Deploy by selection
  47. 47. 7. URL access@tuenti● Good deploy system● Splited environments for production and dev● Most non-public services restricted to vpn + centralized auth
  48. 48. Top 10 security issues in webapps 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 storage10. Insufficient transport layer protection
  49. 49. 8. Unvalidated redirectsUse a service redirect to trick users into clickingon a link (belongs to valid service) and achievemore effective phising/virusdownloads/revenue.
  50. 50. 8. Unvalidated redirects● Explotability: AVERAGE● Prevalence: UNCOMMON● Detectability: EASY● Impact: MODERATE● Prevention: ○ Dont expose destination URL as param, use references to a white list ○ Ensure end URLs are safe (Safe search, user reporting tools...)
  51. 51. Top 10 security issues in webapps 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 storage10. Insufficient transport layer protection
  52. 52. 9. Insecure crypto storageSome data is sensible enought to require beingstored encripted/hashed, to protect it frombeing stolen.Unsalted hashes might be exploitable, backupsmight contain keys or cleartext, services mightexpose decrypt mecanisms, internal attacksmight have access to keys.
  53. 53. 9. Insecure crypto storage● Explotability: DIFFICULT● Prevalence: UNCOMMON● Detectability: DIFFICULT● Impact: SEVERE● Prevention: ○ Keep backups encripted, dont store keys on same place. ○ Use salted hashes and constant time hashes ○ Ensure keys are protected ○ Dont offer full info (credit card XXXX 1234)
  54. 54. Top 10 security issues in webapps 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 storage10. Insufficient transport layer protection
  55. 55. 10. Transport layer protectionAn attacker might sniff traffic of your users tosteal sessions to retrieve data, do spam...
  56. 56. 10. Transport layer protection● Explotability: DIFFICULT● Prevalence: COMMON● Detectability: EASY● Impact: MODERATE● 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.
  57. 57. Top 10 security issues in webapps 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 storage10. Insufficient transport layer protection11. Extras
  58. 58. 11. Extras: Cross domain data leakAjax is changing the web apps, with js-richclients that request data.Beware of exposing JS / JSON user datathrough GET requests without CSRFtokens/headers! <script> tag is not CrossDomain safe!● Require custom header (needs XMLhttpRequest) keep using GET● Check origin header
  59. 59. 11. Extras: ClickjackingTrick 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
  60. 60. 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
  61. 61. 11. Extras: HTTP/Mail Headers● Are subject to CR/LF injection, leading to ○ XSS ○ Spam ○ redirection ○ ...● Use safe api
  62. 62. 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
  63. 63. No input validation?
  64. 64. No input validation?Minimize malformed data, make it matchbusiness 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
  65. 65. 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
  66. 66. Other important aspects
  67. 67. Logging, stats, counters● Very important for security● Stats: ○ Detect issues, patterns to take measures.● Logs ○ Analize issues.● Counters ○ Detect & react to malicious activity
  68. 68. 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
  69. 69. 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
  70. 70. Web Security Future?
  71. 71. Browser XSS protections● Reflexion XSS protection ○ Different implementations IE8, chrome ○ Adds issues, new problems ○ Non perfect, might improve?
  72. 72. Client side templates● Data only requests are easier to escape● Its harder to inject data into client-side templates (only persistent XSS)● Templates might work in DOM mode● SLOW in non recent browsers
  73. 73. Better JS● More secure mashups ○ Google Caja...● More enterprise JS ○ Dart, GWT, Closure, CoffeeScript
  74. 74. Plugins ... Apis ... Browsers● Flash plugin will die!● But new HTML5 apis will bring more issues● Browsers extensions nightmare
  75. 75. Avoid cookiesUsing XMLHttpRequest with sid as param, fromrich JS apps. Destination domain that does nothave cookies.● Decreases attack vectors on: ○ CSRF ○ Click jacking
  76. 76. SSL improvements● HSTS ○ Force SSL ○ Certificate pinning● False start ○ -30% handshake latency
  77. 77. 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)
  78. 78. ?bisho@tuenti.com We are hiring! http://jobs.tuenti.com
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×