OWASP AppSec 2010: A Design Mindset to Avoid SQL Injection and Cross-Site Scripting 2/3
https://www.ispeech.org
Clip 2/3
Speaker: Dan Bergh Johnsson, Omegapoint
SQL Injection and Cross-Site Scripting have been topping the OWASP Top Ten for the last years. It must be a top priority for the community to evolve designs and mindsets that help the programmers to avoid these traps in their day-to-day work, where they have so much else but security that calls for their attention. The ambition of this presentation is to show design and coding practices that are well established in other fields of software development and put them to use to avoid just-mentioned traps. We also show some small refactorings that can be immediately applied to an existing codebase to make significant improvements to its security. Attendants of the session should be able to go back to work Monday morning and finish an improvement in this style before Monday lunch.
We take inspiration from Domain Driven Design (DDD), which is characterized by its focus on what the software intend to represent. In particular, we make heavy use of the Value Object design pattern, where strict typing help us enforce that the incoming data is truthful to the restrictions of the domain. We start out with Injection Flaws and use the canonical username SQL Injection attack ("'OR 1=1 --") as an example. Realizing that mentioned string was not intended as a valid username we elaborate the model to reflect this. Further more we make this change explicit in the code by introducing the new type and class Username. This also gives a natural place to put validation code, which otherwise often is placed in utility classes where it is easily forgotten and seldom called. In fact, we can even design service methods to require a validated Username, thus using the strong typing to enforce validation in the calling client system tier.
Making this re-design with associated code changes is performed as a demo, and en route we discuss other design options and their relative merits and drawbacks. Again using DDD we proceed to analyse XSS. In the same way we see that XSS is in the general case not an indata validation problem. An extended analysis proposes that it can be phrased as an output-encoding problem. Using a similar technique we model the target domain of web content as the new type HTMLString, and can thereby enforce conversion from ordinary strings to strings with the proper encoding. If you have multiple content channels, then each channel will.
All steps needed are shown in code, starting with a vulnerable application and through controlled refactoring steps ending up with a version without the vulnerability. In summary, we will take an established quality practice from another field of software development and use it to get security improvements. The main benefits are two: firstly, the method gently guides and reminds the programmers to include validation and encoding in an unobtrusive way. Secondly, the work can be performed in very small steps, where the first can be finished before lunch Monday after the conference.
For more information click here (http://bit.ly/aeSvg2)
2010-08-31 15:38:22
source
Gloss