Web Application Frameworks Denis Andzakovic – OWASP Day 2012
~# whoami
. My name is Denis Andžakovič . Pen-Tester @ Security-Assessment.com
. A sweeping generalization: . Developers should strive to make my life as difficult as possible. OWASP
. The Top Ten . I am going to assume that we are familiar with this list.
. The recurring theme from previous Web Sec talks has always been ‘Do not roll your own!’
Don’t roll your own!
. Frameworks – <3 . They simplify the development process . There’s less code to write . Code is easily re-used . Code is robust, often heavily tested and integrated with the rest of your framework . They make secure implementations easy (*cough*) . Frameworks make it harder to make mistakes. Frameworks and Pen-Testers
. Makin’ my life difficult. . Secure, robust core code . Often meticulously reviewed and nit-picked . Security guidelines offered for the less sec-savvy developer . Also makin’ my life rather simple :-D . Easier recon . Readily available exploit code (on occasion....) . Implementation errors . Security misconfigurations
Example Framework 1
Google Web Toolkit
. Java based . Compiles Java code into obfuscated JavaScript . Provides a robust RPC implementation for server <-> client communication
How its strung together…
GWT - Overview GWT JavaScript Example RPC request
7|0|7|http://127.0.0.1:8888/owasp_gwt_demo/|9DE0BA7FEFC 7237BEE17C6F7D23512E7| com.example.owaspdemo.client.GreetingService|greetServ er|java.lang.String/2004016611| String1|String2|1|2|3|4|2|5|5|6|7|
. This implementation helps ward off CSRF attacks and helps us defend against XSS attacks. Awesome. Common Mistakes
. Unauthenticated access to RPC endpoints. . UI feature and functionality restriction done on the client side. . Additional Non-GWT functionality compromising XSS and CSRF protections
Unauthenticated access and client side UI restrictions GWT DEMO How to avoid this?
. Understand how the specific framework operates (client side versus server side code) . Ron Gutierrez has a very helpful talk titled ‘Attacking Google Web Toolkit’, which details some common ways to unlock client-side functionality. . Implement stringent access controls . Validate, validate and validate some more. . Do not rely on Security-Through-Obscurity . GDS have provided a set of tools for RPC endpoint enumeration and de- obfuscation of GWT code. (http://blog.gdssecurity.com/labs/tag/gwt) . Google’s GWT Security Recommendations were followed . http://developers.google.com/ provide a very useful article titled ‘Security for GWT Applications’, which includes some easy-to-implement solutions for these issues.
To summarize...
. Client Side. Server Side. These are not the same thing!
. Users are evil, never trust them. Validate all input. Zend Framework
. “A powerful high-quality open-source framework focused on developing modern Web Applications and Web Services”
. Usually uses a MVC design with a dispatcher . Without a Dispatcher, every implemented script must embed or implement authentication – Classic approach prone to human error . Anti-Cross-Site-Scripting Escaping Magic disabled by default . This will change in version 2.0, According to Zend Framework project lead Matthew Weier O'Phinney The Model View Controller More on MVC Common bugs
. SQL Injection . Zend offers several classes for DB access, yet for some reason no one uses them? . Cross Site Scripting issues . Remember how Zend doesn’t have auto anti-XSS magic enabled? . Framework specific vulnerabilities . Specific versions of Zend are vulnerable to certain bugs in the core framework. . Practically the rest of the Top Ten as well... . It’s up to the developer to not do something ridiculous. Who’s been pwned?
. XOOPS – Built on Zend... A quick look on exploit DB shows 68 Bugs... . The majority of these are SQLi and XSS bugs... . Digitalus CMS – Also built on Zend... . A brief search turned up an arbitrary file upload bug, wonderful. . Information disclosure bug in Zend itself . Recently, a vulnerability was discovered in Zends XMLRPC package. X-Oops
. SQL Injection
X-Oops 2
. XSS – Our POC.
. The culprit code.
Digitalus Fail
. ‘An attacker can exploit this vulnerability via browser by following this link: http://
. 3rd Party Features stuck onto the app... Great... . Exploitable code, probably not even written by you, has gone and compromised the integrity of your entire application. XXE Bug in Zend XMLRPC What should have been done.
. Zend comes with classes for database access and escaping. . Zend_Db. Zend_Db_Statement. Zend_Db_Table ect . Zend_Db_Select exists to create dynamic SELECT queries, leverages prepared statements internally as often as possible . Ye-Oldie XXS scrubbing is not your friend. . Leverage Zend_View_Helper . Centralize your validation . Work with the controller
. Zend provide a useful webinar detailing some common issues and ways to deal with them . http://static.zend.com/topics/Webinar-Zend-Secure-Application-Development- with-the-Zend-Framework.pdf More on Centralised validation Microsoft .NET Framework
. .NET is basically one giant framework, this thing is huge. . Many popular sites written in .NET . First released in 2002 . Suffers the same issue as the previous frameworks... Devs. Frameworks built on frameworks
. EG: DotNetNuke and Spring.Net . Yet another layer for error 1. Errors with the core framework . Padding Oracle attack... 2. Errors with the framework built on the core framework . DNN Arbitrary file upload bug... 3. Top framework implementing core framework functions incorrectly . DNN-2011-9-C Authorization Bypass 4. Developers implementing Framework itself incorrectly . This one is kind of self explanatory... Vulns :D Doing it wrong.
. As you probably know, GitHub was hacked by a miffed Russian gentleman in June... . This was done via a mass assignment bug. . Yea, okay, technically that was ruby on rails, but the same concepts apply to .NET MVC.
. Umbraco (a .NET based CMS) Remote command execution bug (another one from our friends at GDS)
Mass Assignment Umbraco RCE
. A specially crafted SOAP call results in unauthenticated file upload. . Because calls to this guy are not validated... Doing it right.
. Pay special attention to Model interactions . What can a user change? . MSDN – use it . Colossal amount of documentation, including a fair few helpful tips and tricks under ‘Writing Secure Code’ . Following MSDNs ‘Web Service Security’ guidelines could have avoided the Umbraco issue. . Webcasts and Whitepapers on secure development offer a wealth of knowledge . A good starting point – Security in the .NET Framework . http://msdn.microsoft.com/en-us/library/fkytk30f.aspx Vulnerabilities IN the framework
. So you’ve written a web app based around a framework... . The code has been peer reviewed . The application has been tested by a third party . Everything is happy days
. Now keep an eye on the intertoobz. . Vulnerabilities within the framework itself can compromise the integrity of your application
. Example: Zend XXE bug Misconfiguration
. Information disclosure is bad for you. . While it might not be a vulnerability as such... . It shows the attacker where to swing the hammer... . Remember to lock down your production Implementations!
. Example: Don’t forget to turn off debug... A quick recap – Dos and Don’ts
. Do think things through, understand what your code and framework of choice is doing. . Embrace your framework . Use the available filtering and security routines where available. OWASP ESAPI is a good choice where said routines are not available, or a different framework entirely... . Implement secure coding practices . Do -NOT- include 3rd party code and plugins . Less code, less problems. It’s as simple as that. . Have your code peer-reviewed . Have your application pen-tested
Try to avoid horrible software.
What to look for in a framework: . Is it fit for purpose? . Security Features . Good documentation . Bonus points for brilliant documentation . Secure development guidelines . If there were bugs released, how did the vendor respond? . Eg – Zend’s prompt patching of the XXE bug.
Remain Vigilant and Be Pedantic
To design, deliver and operate a web application securely, it’s key to: . Be pedantic about your implementations . Double check all configs before going into prod . Probably a good idea to remove README, INSTALL, LICENSE etc. as well... . Be vigilant when writing new code . Think ‘who could potentially mess with this’ and go from there... . Kick your rookies until they understand. . Feed and Water – you have ops guys for a reason . Keep things up to date. . Have a penetration test done by a reputable company Fin.
. Questions? Comments? . Denis Andzakovic – [email protected] Security-Assessment.com are looking for Pen-Testers. Got skills? Give us a call.