John Melton's Weblog
Java, Security and Technology
Java, Security and Technology
What is it and why should I care?
Libraries and frameworks are a reality for every J2EE developer (pretty much any developer, actually) out there. We use them for MVC, DB, logging, web services, security, XML processing, as well as a host of other features. We rely on them in our production apps every single day. All this code written by someone else. Code that likely hasn’t been internally vetted. Code that likely hasn’t even been looked at. Yet, we still use these masses of code (generally MUCH larger than the custom code written for the app itself) to add functionality to our applications.
Knowing your frameworks means you don’t accept the code blindly. When you include a piece of software in your application, you’ve inherited and are now responsible for it. From a functionality perspective, you fix it when it breaks. From a security perspective, you are now responsible for dealing with it’s vulnerabilities. This is the crux of the problem: we manage a LOT of code now (code we didn’t write) and are responsible for making sure it is functional and secure: no easy task.
What should I do about it?
There are many things you should do when dealing with frameworks. I’ll cover the two I think are most important.
First, you should patch your frameworks when new vulnerabilities are found. This is a significant effort because it obviously requires much testing and coordination to upgrade frameworks within applications. However, there have been significant vulnerabilities found in libraries that are extremely popular, and that necessitates patching. Sometimes, patching can be done without upgrading the library actually. It could be moved off to a WAF or some such product. The point is you need to prevent the vulnerability that’s been exposed.
Second, you should really know and understand how your framework functions. While most frameworks patch vulnerabilities reasonably quickly (especially if the vuln public knowledge), they will often not patch their “design decisions”. These are often architectural patterns that benefit functionality, but not security. One popular pattern that comes to mind is auto-binding / mass assignment. The technique of populating the model using request data is not new, and is very powerful. It can make code much easier and cleaner to write. However, it’s often implemented with no security at all. The best you’ll usually get is an opt-in mechanism for securing it. However, most people are not going to opt-in, so it will be used insecurely in many cases. Patterns like this are frequently seen in modern frameworks, and developers really need to be aware of what’s going on internally in the framework to understand how the security and functionality of their application is going to be affected.
Frameworks are a necessary piece to most any development work going on today, but blindly trusting them is not. Be aware of what the frameworks you’re using do and how they do it. Keep an eye on them and patch them as necessary. This will help manage the risk of using them in your applications.
This post turned out to be very timely. Aspect Security just put out a nice paper (sorry, behind registration wall) on some analysis they did regarding the usage of java libraries through the maven central repo. They analyzed 113 million downloads and found that 26% of those downloads have known vulnerabilities! That’s a significant number. Their analysis doesn’t say whether or not those downloads were followed by requests for the patched versions, but I would bet not.
References
———–
https://www.aspectsecurity.com/blog/the-unfortunate-reality-of-insecure-libraries/
What is it and why should I care?
Log forging is an issue that can occur if you allow un-trusted data to be written to a log storage mechanism. The intent of the attacker using log forging is to cover his tracks in the logs or at least make understanding what he was doing more difficult. Unfortunately, like most log-related issues, it’s generally not a concern until something happens and you actually need the logs.
A simple example of log forging might look like this: (first the code)
String someVar = getRequestParameter("xyz");
log("Data is: " + someVar);
And now for what a normal request and the associated log entry might look like:
?xyz=my name is Bob [2012-03-15 02:04:31] [bob] Data is: my name is Bob
And finally what a forged request and the associated log entry might look like:
?xyz=my name is Bob\r\n[2012-03-15 02:04:39] [mary] Mary created new user\r\n[2012-03-15 02:04:46] [josh] Josh logged out\r\n[2012-03-15 02:04:55] [susan] Susan performed an important transaction [2012-03-15 02:04:31] [bob] Data is: my name is Bob [2012-03-15 02:04:39] [mary] Mary created new user [2012-03-15 02:04:46] [josh] Josh logged out [2012-03-15 02:04:55] [susan] Susan performed an important transaction
The idea here is that the attacker has surmised what a standard log entry might look like and then using simple newline characters created what appear to be new legitimate log entries.
Note: If you are using a database for logging, you likely won’t have as much of an issue since each entry is going to be in a single row. However, it could still affect you if your log viewer doesn’t distinguish between rows. However, you still need to be aware of SQL injection here, which is actually a much more serious issue.
What should I do about it?
Fortunately, log forging has a relatively simple fix.
The general approach is to validate input (you should already be doing this) and encode output (you also should be doing this). Validating input alone is not generally going to stop this attack, since there are valid cases to allow input with newlines. Encoding output in addition to validating the input, however, should solve your problem. There are various options for encoding depending on your needs. A simple fix might be to strip out any user-supplied newlines or replace them with some benign character or character sequence. Another alternative might be to HTML encode the data before storing it. This allows you to decode the data later if you need to get back to the original data, as well as have it set up nicely for a web-based log viewing experience if that’s desirable.
Log forging is a simple issue to understand and solve – it just takes some planning ahead to deal with properly. You’ll be glad you did though when you get that 3am call to look through the logs and figure out what’s happening!
I’ve actually already written a longer, more detailed article about log forging prevention here, but this shorter version was meant to show the essentials and fits in with the year of security for Java content.
References
———–
http://www.jtmelton.com/2010/09/21/preventing-log-forging-in-java/
What is it and why should I care?
X-XSS-Protection is a Microsoft IE technology used to help prevent reflected XSS attacks in IE.
Note 1: This is not a “panacea” for XSS. There is no excuse for not developing your site in a secure manner to prevent XSS. This however is a protection offered by the browser itself (as opposed to an application), meant to protect the masses from the vast amount of XSS litter on the internet.
Note 2: Firefox (by way of NoScript), Chrome (by way of WebKit) and Safari(also WebKit) have similar protections, but apparently don’t use the X-XSS-Protection header as a controlling mechanism.
The XSS protection provided essentially checks for request content that is matched in the response and would cause an XSS vulnerability to be exploited. The filter then performs some mangling of the content to prevent the attack from succeeding. According to the docs, IE has the protection turned on by default for most security zones, including the Internet zone, which is the primary concern for most users.
What should I do about it?
The first thing you should do is work towards resolving any and all XSS issues in your application. As a security minded developer, this is a must.
The recommendation for the use of this header is actually not so straightforward in my opinion. In general, the other HTTP headers I’ve described already in the series have had very little downside. However, the X-XSS-Protection header has had some problems in the past. As far as I’m aware, the IE folks have done a good job of dealing with the known vulns, but I still have concerns since some of the vulns have exposed security problems.
In general, I would recommend keeping the protection enabled, unless you are very sure you have XSS all cleaned up in your app. However, this comes with the caveat that you should at least put some thought into the use cases in your site first. Depending on your choice, here are the options you have available to use, and how you enable them in your application using the X-XSS-Protection HTTP header.
1. Enable the protection for all security zones in blocking mode (Blocking mode means the site won’t display at all if an XSS attempt is found, but rather a simple warning to the user that the attack has been blocked):
X-XSS-Protection: 1; mode=block
2. Enable the protection for all security zones:
X-XSS-Protection: 1
3. Leave the protection enabled for the default zones:
Do nothing.
4. Disable the protection entirely (I only recommend this in 2 cases: either you’re positive that you’ve completely resolved XSS in your app, or there’s an issue in the XSS filter that you’re aware of that causes an additional vulnerability) :
X-XSS-Protection: 0
The protection provided by the X-XSS-Protection header is not complete, but it does raise the bar against attackers and helps protect users. While there have certainly been some implementation issues, the fact that all the major browsers have some implementation of reflected XSS protection shows the importance of this issue. Be prudent in implementation, but certainly do everything you can to help your users be safe.
References
———–
http://blogs.msdn.com/b/ieinternals/archive/2011/01/31/controlling-the-internet-explorer-xss-filter-with-the-x-xss-protection-http-header.aspx
http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx
http://blogs.msdn.com/b/mikeormond/archive/2009/01/26/ie8-cross-site-scripting-xss-protection.aspx
http://msdn.microsoft.com/en-us/library/dd565647(v=vs.85).aspx
http://michael-coates.blogspot.com/2009/07/ie-8-anti-xss-bit-overblown.html
http://jeremiahgrossman.blogspot.com/2010/01/to-disable-ie8s-xss-filter-or-not.html
http://www.jtmelton.com/2009/01/12/the-owasp-top-ten-and-esapi-part-2-cross-site-scripting-xss/
http://michael-coates.blogspot.com/2009/11/ie8-xss-filter-bug.html
http://xforce.iss.net/xforce/xfdb/47442
http://hackademix.net/2009/11/21/ies-xss-filter-creates-xss-vulnerabilities/
http://www.theregister.co.uk/2009/11/20/internet_explorer_security_flaw/
What is it and why should I care?
X-Content-Type-Options is an HTTP header that can help prevent browser content-type sniffing problems.
The content-type for a given resource should match the “type” (too obvious?) of the resource. For example, an HTML page would use “text/html”, a PNG image would use “image/png”, and a CSS document would use “text/css”. However, often times, the content-type is either not specified or is wrong. This has led to browsers having to implement “sniffing” algorithms to determine what the actual data is that is being served, and then apply the appropriate parsing and execution semantics for the sniffed type. This, however, has caused certain bugs. One well-known example allowed attackers to have files that were supposedly images be interpreted as javascript and executed.
What should I do about it?
There are actually 2 things to do here.
Step 1. When serving resources, make sure you send the content-type header to appropriately match the type of the resource being served. For example, if you’re serving an HTML page, you should send the HTTP header:
Content-Type: text/html;
Step 2. Add the X-Content-Type-Options header with a value of “nosniff” to inform the browser to trust what the site has sent is the appropriate content-type, and to not attempt “sniffing” the real content-type. Adding this additional header would look like this:
X-Content-Type-Options: nosniff
These 2 simple steps will provide additional protection against content-type sniffing issues.
An important note to mention here is that while this is a useful protection, not all browsers have implemented it. As of this writing (3/6/2012), only Chrome and IE support this protection (though NoScript does apparently add the protection to Firefox). Even though it won’t save all your users, it’s a useful mechanism to provide even more assurance for your users.
References
———–
http://www.browserscope.org/?category=security
http://blogs.msdn.com/b/ieinternals/archive/2011/02/11/ie9-release-candidate-minor-changes-list.aspx
http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx
http://msdn.microsoft.com/en-us/library/gg622941(v=vs.85).aspx
http://htaccess.wordpress.com/2009/09/22/x-content-type-options-nosniff-header/
http://www.adambarth.com/papers/2009/barth-caballero-song.pdf
http://www.w3.org/TR/html4/types.html#h-6.7
http://hackademix.net/2010/10/30/x-content-type-options-noscript-and-browserscope/