Learning how to write secure web apps
If you write web applications you owe it to yourself, your company, and your users to have some knowledge of the exploitation techniques that will be used against it. Knowing the techniques helps you write more secure code.
The obvious way to learn about such things is to read books or security web sites. The more interesting (OK, fun!) way of doing it is to actually perform the exploits against against a purposefully insecure web application that’s built to be hacked.
OWASP has had such an application for years. WebGoat is an insecure J2EE application that provides lessons on how to exploit the weaknesses. I tried this awhile ago and it’s really eye-opening from a non-hacking developer’s perspective.
Google has just created a similar application called Jarlsberg. Jarlsberg runs on Google’s AppEngine and is written in Python. However, language choice doesn’t matter much when it comes to security vulnerabilities in web applications. Like WebGoat, Jarlsberg teaches you how to perform the exploits in a series of hands-on lessons.
I haven’t tried Jarlsberg yet but it’s on my list of things to do.
Friendlier Navigation Syntax in WLST
In WLST (WebLogic Scripting Tool), how many times have you wished you didn’t have to type the parentheses or quotes when navigating MBeans? For me, I wished for that every time.
Fortunately, WLST designer Satya Ghattu lets us in on a little secret. Simply enter easeSyntax() while in online mode and you can drop the parentheses and quotes when navigating. Using Satya’s examples:
turns into the friendlier
Thanks for the tip, Satya!
XSS and Web Frameworks
Matt Raible recently blogged about Java Web Frameworks and XSS. The post and the comments are well worth reading. It’s easy to think (hope!) that a framework will automatically escape output to prevent XSS and give no more thought to it. As Matt’s post shows, you really need to know how your chosen framework deals with the issue.
If you use Struts 2 or WebWork be sure to read the post and update your libraries.
What happens when a servlet (or JSP) forwards the user to a protected resource for which the user does not have authorization? According to the servlet specification, the user will see the protected resource. Surprise!
I checked the servlet specifications on this subject. Servlet 2.2 has no explicit mention of what happens during forwards or includes from a security perspective. Starting with Servlet 2.3, however, section SRV.12.2 explicitly states that declarative security does not apply to forwards and includes.
I’d prefer it to default the other way such that the container checks security for forwards and includes. Too bad for me, I guess. Fortunately, WebLogic meets the specification’s requirement by default but provides a way to check security if you want to enable it. To use it, add the following stanza to weblogic.xml:
Now, authorization will be checked for the target forward or include.