(IN)SECURE AJAX-Y WEBSITES WITH PHP Christian Wenz
Some Statistics 9 out of 10 web sites have security vulnerabilities. whitehat website security statistics report, March 2008 7.72% of web sites can be automatically compromised. 96.85% of web sites can be compromised with manual means.  WASC Web Application Security Statistics Project 2007 Jun 5, 2009   |     |
Why?  // The Problem Numerous talks, whitepapers, articles  and books on web application security Foundation of non-profit organizations  like  OWASP Heightened awareness in the media But it does not seem to help Jun 5, 2009   |     |
Why?  // "Hall of Shame" Recent evaluation of two dozen ramdomly picked Web 2.0 sites had an incredible "success rate" Some high-profile sites have had issues, too Most notably: MySpace, Facebook, Orkut, ... Jun 5, 2009   |     |
Why?  // Explanations Bad, inconsistent advice in talks, whitepapers, articles and books Lack of time Ajax applications make it very easy to introduce vulnerabilities Many new (unchecked?) server APIs Applications rely on UGC (user-generated content) Jun 5, 2009   |     |
Why?  // Traditional Model Jun 5, 2009   |     | Server Client
Why?  // Ajax Model Jun 5, 2009   |     | Server Client
XSS  // Problem Cross-Site Scripting (XSS) (Old) Problem: Dynamic data is sent to the client – without validation  The following content can be dangerous HTML CSS JavaScript Jun 5, 2009   |     |
XSS  // New Dangers XSS everywhere XML RSS HTTP Headers … Validate  all  incoming data! Validate in all dynamic files! Including REST-y web service APIs; not only Ajax applications may use them! Jun 5, 2009   |     |
XSS  // More Dangers Fancy XSS XSS without JavaScript Advanced JavaScript Attacks using embedded media The browser's same origin policy does not help much Filter using a whitelist approach, not blacklist! Jun 5, 2009   |     |
CSRF  // Problem Cross Site Request Forgeries (CSRF) Problem: HTTP requests do not always happen voluntarily Victim (client) Attacker (web site) Other web site (1) Requests page (2) Sends JavaScript (3) Requests page Jun 5, 2009   |     |
CSRF  // Countermeasures As user Logout whenever possible, as soon as possible Do not visit unknown sites Apart from that almost no chance to prevent attacks As developer Request login before „critical“ operations Include secret/random token in forms Use random names for form elements (?!) Jun 5, 2009   |     |
SQL Injection  // Problem SQL Injection (Old) Problem: Dynamic data is used in SQL statements – without validation  The list of attacks does not end with  ' OR ''='  ! Jun 5, 2009   |     |
SQL Injection  // Bad Ideas Filter for „1=1“ Filter for  ' Filter for # Filter for -- What's next?! Again: No blacklist, but whitelist Or database-specific escape functions/methods Or even better: Prepared statements (if supported) Jun 5, 2009   |     |
SQL Injection  // Fancy attacks Prompting error messages UNION  attacks Blind SQL attacks Using built-in functionality Second-order attacks DoS attacks Jun 5, 2009   |     |
Ajax  // JavaScript attacks JavaScript Hijacking Vulnerable: GET requests that retrieve JSON information Malicious JavaScript code overrides constructors, enabling to intercept and steal (or modify) JSON data http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf   Jun 5, 2009   |     |
Ajax  // Countermeasures Require POST for server APIs Demand a certain HTTP header (e.g.  Content-type: application/json ) Jun 5, 2009   |     |
Ajax  // Further Concerns Need to maintain state Bookmarks Back/forward buttons Usually implemented using the hash portion of the URL Then, parsed upon load Check your parser! Don't get me started with mashups! Jun 5, 2009   |     |
XML  // XML attacks Feeding web services with incorrect XML XPath Injection Nasty entities All input is evil! Jun 5, 2009   |     |
Regular Expressions  // RegEx attacks Problem:  e  modifier in regular expressions Extremely dangerous if user-supplied  data is embedded in this regular  expression Arbitrary code execution may be  possible Jun 5, 2009   |     |
Automation  // Trackbacks Problem: Spammers create trackbacks  to weblogs to get their URL mentioned and therefore increasing their Google  PageRank Trackback API is very simple POST http://victim.tld/trackback?id=0815 Content-type: application/x-www-form-urlencoded title=Buy+stuff&url=http://spammer.tld/&excerpt= Buy+my+stuff&blog_name=Spamblog Jun 5, 2009   |     |
Automation  // Comments Problem: Spammers (automatically) post  comments to weblogs to get their URL  mentioned which in turn might increase their Google PageRank Also works with feedback forms and  „send-a-friend“ features of websites Jun 5, 2009   |     |
Automation  // CAPTCHAs Completely Automated Turing  Test to Tell Computers and  Humans Apart Turing tests: Decide whether the communication partner is a person or a machine Mostly, an image with text/numbers ASCII and audio CAPTCHAs also  exist Jun 5, 2009   |     |
CAPTCHAs  // Countermeasures Implementation bugs Cheap workers Horny surfers Jun 5, 2009   |     |
Because!  // Conclusion There is no 100% security But you should try Rule #1: Validate all input Rule #2: Escape all output Ajax applications do not always generate new attacks, but allow more entry points Better paranoid than offline ™ Jun 5, 2009   |     |
Christian's Conference Guide Tomorrow's security- and Ajax-related sessions Security 11:00am, Hall B: Lesser Known Security Problems in PHP Applications 2:45pm, Hall B: Security-Centered Design (Hall B) Ajax 11:00am, Room 203: The Power and Beauty of Dojo 1:30pm, Hall B: State of Ajax (Keynote) 2:45pm, Room 209: Building RIA with ZF and PHP 4:00pm, Room 203: PHP and Ajax Made Easier with Zend Jun 5, 2009   |     |
Thank You! http://www.hauser-wenz.de/blog/ [email_address]   Please don't forget the session evals! Jun 5, 2009   |     |

(In)Secure Ajax-Y Websites With PHP

  • 1.
    (IN)SECURE AJAX-Y WEBSITESWITH PHP Christian Wenz
  • 2.
    Some Statistics 9out of 10 web sites have security vulnerabilities. whitehat website security statistics report, March 2008 7.72% of web sites can be automatically compromised. 96.85% of web sites can be compromised with manual means. WASC Web Application Security Statistics Project 2007 Jun 5, 2009 | |
  • 3.
    Why? //The Problem Numerous talks, whitepapers, articles and books on web application security Foundation of non-profit organizations like OWASP Heightened awareness in the media But it does not seem to help Jun 5, 2009 | |
  • 4.
    Why? //"Hall of Shame" Recent evaluation of two dozen ramdomly picked Web 2.0 sites had an incredible "success rate" Some high-profile sites have had issues, too Most notably: MySpace, Facebook, Orkut, ... Jun 5, 2009 | |
  • 5.
    Why? //Explanations Bad, inconsistent advice in talks, whitepapers, articles and books Lack of time Ajax applications make it very easy to introduce vulnerabilities Many new (unchecked?) server APIs Applications rely on UGC (user-generated content) Jun 5, 2009 | |
  • 6.
    Why? //Traditional Model Jun 5, 2009 | | Server Client
  • 7.
    Why? //Ajax Model Jun 5, 2009 | | Server Client
  • 8.
    XSS //Problem Cross-Site Scripting (XSS) (Old) Problem: Dynamic data is sent to the client – without validation The following content can be dangerous HTML CSS JavaScript Jun 5, 2009 | |
  • 9.
    XSS //New Dangers XSS everywhere XML RSS HTTP Headers … Validate all incoming data! Validate in all dynamic files! Including REST-y web service APIs; not only Ajax applications may use them! Jun 5, 2009 | |
  • 10.
    XSS //More Dangers Fancy XSS XSS without JavaScript Advanced JavaScript Attacks using embedded media The browser's same origin policy does not help much Filter using a whitelist approach, not blacklist! Jun 5, 2009 | |
  • 11.
    CSRF //Problem Cross Site Request Forgeries (CSRF) Problem: HTTP requests do not always happen voluntarily Victim (client) Attacker (web site) Other web site (1) Requests page (2) Sends JavaScript (3) Requests page Jun 5, 2009 | |
  • 12.
    CSRF //Countermeasures As user Logout whenever possible, as soon as possible Do not visit unknown sites Apart from that almost no chance to prevent attacks As developer Request login before „critical“ operations Include secret/random token in forms Use random names for form elements (?!) Jun 5, 2009 | |
  • 13.
    SQL Injection // Problem SQL Injection (Old) Problem: Dynamic data is used in SQL statements – without validation The list of attacks does not end with ' OR ''=' ! Jun 5, 2009 | |
  • 14.
    SQL Injection // Bad Ideas Filter for „1=1“ Filter for ' Filter for # Filter for -- What's next?! Again: No blacklist, but whitelist Or database-specific escape functions/methods Or even better: Prepared statements (if supported) Jun 5, 2009 | |
  • 15.
    SQL Injection // Fancy attacks Prompting error messages UNION attacks Blind SQL attacks Using built-in functionality Second-order attacks DoS attacks Jun 5, 2009 | |
  • 16.
    Ajax //JavaScript attacks JavaScript Hijacking Vulnerable: GET requests that retrieve JSON information Malicious JavaScript code overrides constructors, enabling to intercept and steal (or modify) JSON data http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf Jun 5, 2009 | |
  • 17.
    Ajax //Countermeasures Require POST for server APIs Demand a certain HTTP header (e.g. Content-type: application/json ) Jun 5, 2009 | |
  • 18.
    Ajax //Further Concerns Need to maintain state Bookmarks Back/forward buttons Usually implemented using the hash portion of the URL Then, parsed upon load Check your parser! Don't get me started with mashups! Jun 5, 2009 | |
  • 19.
    XML //XML attacks Feeding web services with incorrect XML XPath Injection Nasty entities All input is evil! Jun 5, 2009 | |
  • 20.
    Regular Expressions // RegEx attacks Problem: e modifier in regular expressions Extremely dangerous if user-supplied data is embedded in this regular expression Arbitrary code execution may be possible Jun 5, 2009 | |
  • 21.
    Automation //Trackbacks Problem: Spammers create trackbacks to weblogs to get their URL mentioned and therefore increasing their Google PageRank Trackback API is very simple POST http://victim.tld/trackback?id=0815 Content-type: application/x-www-form-urlencoded title=Buy+stuff&url=http://spammer.tld/&excerpt= Buy+my+stuff&blog_name=Spamblog Jun 5, 2009 | |
  • 22.
    Automation //Comments Problem: Spammers (automatically) post comments to weblogs to get their URL mentioned which in turn might increase their Google PageRank Also works with feedback forms and „send-a-friend“ features of websites Jun 5, 2009 | |
  • 23.
    Automation //CAPTCHAs Completely Automated Turing Test to Tell Computers and Humans Apart Turing tests: Decide whether the communication partner is a person or a machine Mostly, an image with text/numbers ASCII and audio CAPTCHAs also exist Jun 5, 2009 | |
  • 24.
    CAPTCHAs //Countermeasures Implementation bugs Cheap workers Horny surfers Jun 5, 2009 | |
  • 25.
    Because! //Conclusion There is no 100% security But you should try Rule #1: Validate all input Rule #2: Escape all output Ajax applications do not always generate new attacks, but allow more entry points Better paranoid than offline ™ Jun 5, 2009 | |
  • 26.
    Christian's Conference GuideTomorrow's security- and Ajax-related sessions Security 11:00am, Hall B: Lesser Known Security Problems in PHP Applications 2:45pm, Hall B: Security-Centered Design (Hall B) Ajax 11:00am, Room 203: The Power and Beauty of Dojo 1:30pm, Hall B: State of Ajax (Keynote) 2:45pm, Room 209: Building RIA with ZF and PHP 4:00pm, Room 203: PHP and Ajax Made Easier with Zend Jun 5, 2009 | |
  • 27.
    Thank You! http://www.hauser-wenz.de/blog/[email_address] Please don't forget the session evals! Jun 5, 2009 | |