What is it and why should I care?
While trust spawns interesting philosophical discussions, here I want to discuss the implications of trust within the applications we build. Trust is a funny thing in that we implicitly give it frequently without considering what we’re trusting. A simple example:

//bad bad do not use
executeDbQuery("select * from my_table where id = " + request.getParameter("my_id"));
//bad bad do not use

Here we’ve said that we trust that the user of the application has not tampered with the my_id request parameter in any way that may cause problems for our application. Obviously this is a poor assumption. We can do better by moving the above query to a prepared statement with parameter binding to prevent SQL injection and we can also validate the my_id parameter for appropriate input, but why do we do that?

It’s because we don’t trust the input to our system. We don’t (and shouldn’t) trust that a user or system is going to use our application in the way we would expect, or even the ways we’ve thought of necessarily (a good reason against blacklisting for security). We must build systems that not only are functional (use) but stand up under attack (abuse) or ignorant usage. Our systems must be robust or as some have called it, rugged. Whatever your term, the idea of trust is either explicitly or implicitly central to the idea. We can’t trust the environment.

If we can’t trust the environment, what does that mean? Does that mean we deal with XSS and SQLi? Yes, but much more than that, it’s a different way of thinking about the application. It becomes that simple picture of input-processing-output at varying levels of scope. A single request has inputs (request parameters, headers, database input, etc.), processing (authn/z, logic, etc.) and outputs (DB, screen, file, etc.). The application as a whole has inputs, processing and outputs that are essentially the combination of all the individual components of the application, and then you can scale on up to systems and organizations.

The “environment” I’m referring to changes depending on your specific situation, and it’s difficult to say that you simply can’t trust anything, because that’s usually a non-starter. You may have to trust your configuration files or your external SSO system, or any number of other entities. The idea is that you specifically label those things as trusted (an assumption) and treat everything else as being tainted.

These types of issues are considered in threat modelling, which is another planned topic in this series. For now, it’s sufficient to simply note that you should be thinking in terms of what data am I taking in, processing and sending out?

What should I do about it?
Now that we’ve established the environment can’t be trusted, the next logical question is what constitutes the environment?

This could be a long answer depending on your setup, but a decent starting list for web applications in particular might look like the following:

• web request data (parameters, headers, body, cookies)
• database data
• directory data (ldap)
• filesystem data
• web service data (any data in headers or body)
• external system data (any data you receive from another system – software you’re integrating with)
• network connection data (any data you receive while acting as the “server” – generally socket-based communication)
• user input (command line input)
• system environment variables
• third party software (libraries that you call that provide you data)

This list is incomplete I’m sure, but the idea is there. Any data you receive from any of these users or systems is generally untrusted, possibly with certain organization/application-specific well defined exceptions. When you start to view your applications in this way, you start to build better protections around them. You build better defences, and better logging/auditing so that you can detect when something actually does break (it will, I promise). However, thinking in this way can go a long way to helping you build safer and more secure systems.

References
———–
http://www.ruggedsoftware.org/
http://www.schneier.com/book-lo.html
http://en.wikipedia.org/wiki/Robustness_principle
http://www.jtmelton.com/2012/05/01/year-of-security-for-java-week-18-perform-application-layer-intrusion-detection/
http://www.jtmelton.com/2012/04/10/year-of-security-for-java-week-15-audit-security-related-events/

Technorati Tags: Trust Nothing

What is it and why should I care?
Reducing the attack surface of an application or system means reducing the ways that you can interact with the application, and may involve reducing the functionality the application provides.

To most business folks, this sounds very, very bad. However, at its’ core, it’s really just a matter of simplifying the system. This is a really *good* thing to the business. Rarely do you find anything that people genuinely enjoy using that is complex. The best designs are simple, and that benefits us in this case from a security perspective.

What does this simplification look like? My favorite example is the difference between Google’s standard and advanced searches. It’s likely that 99.9% of people don’t need the advanced search features. Imagine if google removed that page – that greatly simplifies the “search” application they build. It reduces the application footprint, saves them money (dev, support, etc) and gives their customers a better experience – what could be better? (Note: I’m simplifying this case as google’s standard search does allow advanced operators, but you get the idea.)

Most developers I’ve worked with (myself included) have the tendency to a) want to build lots of cool stuff, and b) be poor designers. This results in designs that are larger than necessary in that they encompass more code than planned (feature creep). It also results in an often unpleasant user experience. By being ruthless in removing non-required functionality, and simplifying what is required, the user experience is enhanced along with security, not to mention the bottom line – time and money.

What should I do about it?
Saying you should remove features/functionality and simplify is a bit vague, I realize. I’d like to offer a few examples of common situations where you might be able to have some impact on your applications for the better.

1. Dead Code
Every modern IDE has a “dead code” detector. If you don’t use an IDE, tons of open source “code quality” tools have this feature as well. Use it. If you’re not using code, remove it. If you comment out code, but keep it in the code-base, stop. Remove it. Heck, you can get it back through your version control if you ever really need it.

As much as you can you should also remove code that is “dead” because it’s not enabled via configuration. This may not always hold depending on the specific circumstance, but if you don’t have a need for a feature, don’t have it in your code base.

Dead code doesn’t get looked at or dealt with as closely as “live” code, so that makes it even worse from a security perspective, as there are likely to be lingering issues that aren’t dealt with because “no one is using that”.

2. Copied code
Everybody’s done it. You’ve taken code from an old project and used it in a new one. You’ve taken an example from the web and plugged it into your app. It may have done more than you needed, even way more. What have you done? You’ve added extra code that has be maintained, debugged, supported, tuned, secured, etc. This is a bad idea. It’s fine to use others’ (assuming they’re ok with it) code, but don’t add a bunch of stuff you don’t need.

3. Extra features
It’s undoubtedly great to wow your customer. In my opinion, adding unplanned features is usually not the best way to do that. Usually, giving them the absolute best version of what they need is much better for both you and them. It’s the idea of doing a few things well as opposed to lots of things just OK. Adding in extra features is a common thing for developers to do, often because they saw some cool thing somewhere and thought “hey – that’d be cool here”. Again, adding extra features means extra code, and that’s more to do, and takes away from the quality of what you actually need to do.

4. Extra code – 3rd party libraries
3rd party libraries are great. They are core to most any development done today. They enable us to create more functional apps quicker. However, they also put into your application TONS of functionality and features you may not have planned on being there, and that you probably don’t know exist. I would venture a guess that most J2EE apps I see probably include hundreds, if not thousands, of times more code in 3rd party libraries than in the code written for the application. That’s great from the perspective of “I didn’t have to write this”, but could mean danger when it comes to securing your application with those frameworks. From a security perspective, it doesn’t help that most of these libraries are there to have things just work instead of having secure defaults. I’m not saying frameworks are bad; I’m saying you need to know their capabilities well, and have a plan for dealing with them from the security perspective.

5. Extra services enabled
This is particularly common with 3rd party applications, but can be true for custom apps as well. What happens is an application is built in a generic way, and then sold/used by several groups or companies to solve different problems or similar problems for different users, etc. The functionality in the app is the sum total of what all the customers need. You as an individual customer might only need 30% of the overall functionality, but you have 100% enabled. That’s a problem. The better apps give you a simple way to disable features you’re not using, and a simple way to verify it’s actually turned off. Use these features. It’s always better to have to do an update to enable a feature than to have to tell your boss you were hacked using a feature that wasn’t even needed.

The above represents just a handful of ideas on how to reduce attack surface in your application. They all really boil down to simplify, simplify, simplify. It helps your application be better, and thankfully helps your security be better as well. Next time you have a bug-hunting session, try some of these ideas out. Also add comments if you have more/better ideas.

References
———–
http://www.jtmelton.com/2012/03/29/year-of-security-for-java-week-13-know-your-frameworks/

Technorati Tags: 3rd Party Libraries, Keep It Simple, Reduce Attack Surface

What is it and why should I care?
Application layer intrusion detection is a simple concept that I believe is very, very powerful when it comes to protecting applications. Most of the topics I’ve covered thus far have focused on the development portion of the software life-cycle, but this topic really covers the entire span of an application, from the requirements and planning to sun-setting.

The basic concept is that you plan for, implement and monitor “bad” things that occur in your application. With this type of system in place, you look for events that appear to be undesirable in some way and then keep track of them. Over time, you can make decisions about whether those individual events turn into an actual attack.

Many developers actually do most of the work of detection already. Consider the following pseudo-code:

if (user has access to record) {
    get data
    redirect to view/edit page
} else {
    log exception
    send user error message
}

I’ve seen code just like this lots of times. The problem here is the handling exceptional condition. In general, people don’t review logs, so if there’s an attacker trying to break your application, the only person seeing the error you’ve caught is the _attacker_. With one quick addition of sending a message to your intrusion detection engine, you can start tracking these events and actually gaining knowledge into the real-time (and historical if you choose to store it) usage of your application. After you’ve detected an actual intrusion, you also have the ability to respond to the activity in any [legal] way you see fit. Popular options include ideas like: increased logging, manipulating user account (logout, disable), or even blocking access to certain functionality.

What should I do about it?
Let’s assume I’ve sold you on the idea of implementing something like this (hopefully I have). What now?

Well, you have a few options on how to proceed that I’m aware of: ESAPI, AppSensor or roll-your-own.

ESAPI does have an intrusion detection engine built-in that performs some of these ideas. It is admittedly not extensive, but the core is there and can certainly be extended.

AppSensor is one such extension of the ESAPI intrusion detection engine. The implementation is more extensive than what’s available for ESAPI. Additionally, the project offers a book about the overall idea, as well as significant documentation in addition to the code. Lastly, there is actually a significant update being worked on currently on the project to update both the documentation and the code.

Rolling your own analysis engine can be a small or very large project depending on your needs. Nevertheless, you can certainly take the ideas and implement them in your applications and get significant benefit.

By just adding a little bit of effort, you can gain significant insight into the overall security health of your application(s). You can see who attacked/is attacking your application in real-time or the past, and you can actually respond to events as they occur. Who wouldn’t like that?

Author note: I work on the AppSensor project, so this whole topic is near and dear to me. Please take advantage of the idea whether it’s in our implementation or not!

References
———–
https://www.owasp.org/index.php/ApplicationLayerIntrustionDetection
http://www.jtmelton.com/2010/11/10/application-intrusion-detection-with-owasp-appsensor/
http://www.owasp.org/index.php/OWASP_AppSensor_Project
http://www.owasp.org/
http://www.youtube.com/watch?v=6gxg_t2ybcE
http://www.clerkendweller.com/2010/11/12/Application-Intrusion-Detection-and-Response-Planning-Methodology
https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

Technorati Tags: Application Layer Intrusion Detection, AppSensor, OWASP, Security

What is it and why should I care?

A session timeout is an important security control for any application. It specifies the length of time that an application will allow a user to remain logged in before forcing the user to re-authenticate. There are 2 types: Soft Session Timeouts (last week’s topic) and Hard Session Timeouts (this week’s topic).

A hard session timeout is applied when the user has been logged in for a specific period of time, no matter what.

As an example, lets say we have a system where:
1. Access to the application requires authentication
2. Attempting to access any portion of the application except login (and change/reset pw, etc.) redirects you to the login page.
3. A user logs into your system and uses the system, actively or inactively, for 9 hours and you have a hard session timeout that is set to 9 hours

The net effect of this will be that the next interaction this user has with the system will then redirect them to the login page.

The section above shows what a hard session timeout is and does, but what is it protecting against? Whereas a soft session timeout is angled more towards preventing CSRF and similar attacks, a hard session timeout (while it does help protect against those as well) is helpful to prevent things like the permanent hijacking of an account. If an attacker does overtake an account, they can’t use it forever without re-authentication. For this same reason, you should force authentication (validate old password) whenever a user attempts to change the password of the account.

What should I do about it?

Many applications, even those that avoid the soft session timeout, do include a hard session timeout. Unfortunately, it’s not available simply to Java developers as an option for configuration. That means you have to either roll your own, or look for some existing software outside of the core Java/J2EE options.

In Java, there are a few ways you can enable a hard session timeout:

Option 1: Set timeout in code

There is no specific Java API call to do this. However, you could easily setup a filter (or your handler/interceptor of choice) to perform this task. Essentially it would require you to store the last logged in time of every user and tie that to their authenticated session id. If a request is made using a session id tied to a user who has been logged in > X minutes, invalidate the session, and redirect the request to the login screen. Fairly simple idea.

Option 2: Use a third party library

Though I’m not aware of any libraries off the top of my head that do this, it wouldn’t be hard to theoretically. (If one doesn’t exist, you could always build it and donate it to the community!)

Option 3: SSO sets the timeout

This is not a Java-only option, but still should be mentioned. Many enterprises use large single sign-on (SSO) identity systems to control access to applications. Many of these systems allow you to set the timeout (both a soft timeout and a hard timeout) for an application.

As you can see, the hard session timeout is a useful security control. It allows you to have another layer of protection for your application and your users.

References
———–
http://www.jtmelton.com/2012/04/17/year-of-security-for-java-week-16-set-a-soft-session-timeout/

Technorati Tags: CSRF, session timeout

What is it and why should I care?

A session timeout is an important security control for any application. It specifies the length of time that an application will allow a user to remain logged in before forcing the user to re-authenticate. There are 2 types: Soft Session Timeouts (today’s topic) and Hard Session Timeouts (I’ll cover this next week).

A soft session timeout is applied when the user does not interact with the system for a period of time.

As an example, lets say we have a system where:
1. Access to the application requires authentication
2. Attempting to access any portion of the application except login (and change/reset pw, etc.) redirects you to the login page.
3. A user logs into your system and walks away for 20 minutes and you have a 15 minute timeout
The net effect of this will be that the next interaction this user has with the system will then redirect them to the login page.

The section above shows what a soft session timeout is and does, but what is it protecting against? There are many issues that are related (authentication,authorization,auditing,session hijacking, etc.), but one of the primary issues is CSRF. By forcing a reasonably low session timeout, you add another security control that increases the difficulty of launching CSRF style attacks. Essentially, any attack that attempts to exploit the fact that the user is logged in is now either prevented or complicated by using this simple control.

What should I do about it?

Like many security controls, there is a tradeoff with functionality related to session timeouts. Many popular web applications that we use have no soft session timeout configured, because they don’t want to trouble a user with an extra step of logging in repeatedly. As in other situations, this is a risk decision to make things less secure for your users in order to make things simpler and easier for them. If you have an application that protects sensitive data, or your users (or you) have a lower threshold of pain with risk decisions, you should opt for including a soft (and hard – see next week) session timeout.

In Java, there are several ways you can do this.

Option 1: Set the timeout in the web.xml

By far the most popular option, this is simple and allows you to configure this without having to set it in code. An example snippet showing a 15 minute timeout is below.

  15	

Option 2: Allow the app server to set the session timeout

This could mean that you allow the default (30 minutes for most app servers) or that you set the value specifically in your container. Either way, this is an option.

Option 3: Set timeout in code

This option allows you the ability to encode this setting in code. This does allow you the additional flexibility of setting differet timeouts for different users since it’s set on the session and not globally, but it’s far less common than it’s web.xml alternative

httpSession.setMaxInactiveInterval(15*60); // set in seconds

Option 4: SSO sets the timeout

This is not a Java-only option, but still should be mentioned. Many enterprises use large single sign-on (SSO) identity systems to control access to applications. Many of these systems allow you to set the timeout for an application.

As you can see, the soft session timeout is a useful security control. It allows you to have another layer of protection for your application and your users.

References
———–
http://software-security.sans.org/blog/2010/08/11/security-misconfigurations-java-webxml-files

Technorati Tags: CSRF, session timeout, web.xml

What is it and why should I care?
Auditing security related events includes two basic concepts, so we’ll begin by treating them individually.

Auditing
Auditing is a key part of any real software system. Many people treat logging and auditing as the same idea, though they’re actually different. Definitions might vary, but mine boils down to the consumer of the output. In general, logging data is consumed by developers (most often for debugging problems), and possibly business owners to see basic trending information (likely through some basic log parsing for usage statistics, etc). Auditing, on the other hand, is meant to be used by auditors to reconstruct the events that occurred in the system. The view of these events is often constrained by a time period, a specific user or set of users, a specific function or set of functions, etc.

Usually, logged data is unstructured and can be or represent anything. Audit data, on the other hand, is generally structured, and can be thought of more like a database record where there are specific fields that are always filled in, and the only thing that changes is the data in the column, not the column itself (to use the DB analogy).

Security Related Events
Security related events are going to be determined by you as part of your development process, but there are several obvious candidates, such as login, logout, user management, credential management. etc. All of these are clearly security related and could be important to the security posture of your application either generally or specifically related to a single user or set of users.

Knowing that a security related event has occurred is important. Not knowing could lead to not only unauthorized access or usage of the system, but the inability to know that it even occurred.

What should I do about it?
Auditing is the option to choose when you’re talking about security-related events. For any security-related event that occurs in the system, you should be auditing the activity. You should collect appropriate data on each event, such as event type (what happened), actor performing event (who did it), timestamp (when did they do it), etc. This type of data will allow you to filter the dataset by user, time, function, or any of the other data points when needed to determine specifically what occurred from an auditing perspective. Structured data in this form also lets you do helpful things like look at generic patterns and find that a specific user did a bunch of things outside work hours (unusual?) or everyone in the system all performed a single function within an hour of each other (maybe strange?). Some of these ideas are found in the concept of AppSensor, an OWASP project I work on.

I would also like to point out a great talk Gunnar Peterson gave at an OWASP chapter meeting called “Audit Logging Done Right“. That video goes into detail about auditing and the power it has when used appropriately.

Auditing is not a new technology, and often is viewed as a boring “have to do”, but it is actually a very powerful concept that lets us gain access and visibility into what the application is doing. It also gives us all of the nice capabilities of dealing with structured data . Once you recognize the utility, I hope you’ll start auditing a few more things out of the realization of it’s power, not just obligation!

References
———–
http://vimeo.com/15423426 – Gunnar Peterson – Audit Logging Done Right
https://www.owasp.org/index.php/OWASP_AppSensor_Project

Technorati Tags: audit logging, Security, security events

What is it and why should I care?
Java Server Pages (JSPs) is an extremely common UI view technology used in J2EE development. JSPs represent the interface the end user interacts with while using an application. JSPs also usually include some business logic, and frequently there are portions of a page protected by some authorization constraints. Additionally, there are many times other protections in request handling (controller) code that perform some authorization before forwarding users to a given JSP. Bottom line, there is important logic (and at times data) stored in JSPs that shouldn’t be generally accessible to end users without going through the appropriate controls to gain access to them.

Knowing that these resources are important to the application, we’d certainly like to protect them. In general, modern applications rely on frameworks that use an MVC model for accessing an application. What that practically means regarding JSPs is that there is no direct access to the JSP during normal use of the application. You make a request to some type of controller or handler that performs some business logic and then internally forwards to a JSP for rendering. This means JSPs are generally no longer directly accessed, at least on purpose. However, if you store your JSPs in an area accessible to the web without putting them in the WEB-INF (same place where your web.xml goes) directory, they can be directly browsed by users (unless you have other protections in place). This means your pages will most likely break functionally (since they won’t have certain data they are expecting to come from the controller), and they will often times not have the appropriate authorizations performed since those are often expected to occur when a user follows the path through the controller.

Note: These same points could be made about certain types of configuration files, scripts and other types of data included in web applications, but JSPs are generally recognized as the most common resource type that is able to be force-browsed by the end user and contains important data. Also, configuration files for many frameworks work only when they are stored in WEB-INF, simplifying the issue there by forcing you to do it right.

What should I do about it?
The Servlet Specification defines that the WEB-INF directory of a deployed application is not to be directly accessible by external users. In other words, if a request is made for a resource in WEB-INF, it will be rejected. The only way this won’t be the case is if there is a bug in the application server running your application.

For this reason, you should store your JSPs in WEB-INF. This way, your application will still be able to use them, since forwarding to a resource in WEB-INF happens server-side and doesn’t present an access issue. Additionally, you prevent external users from being able to request them successfully by force browsing to them.

One thing to be aware of is that code that does file manipulation (read, write, move, etc.) on server-side files is still able to access the WEB-INF directory. This means there are still plenty of bugs out there where you can do directory traversal to read the web.xml file in the WEB-INF directory. The WEB-INF directory does prevent access to external direct requests, but not to code that runs server-side – definitely something to watch out for.

Storing your JSPs in the WEB-INF directory is a very simple and effective mechanism that offers protection against forced browsing attempts, and you can and should use it to provide an additional layer of protection to your applications.

Technorati Tags: Forced Browsing, Java Server Pages, JSP, WEB-INF

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/

Technorati Tags: frameworks, J2EE, Java, libraries, Patching, Security, third party

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/

Technorati Tags: J2EE, Java, Log Forging, Security

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/

Technorati Tags: Cross Site Scripting, Encoding, J2EE, Java, Security, X-XSS-Protection, XSS