Last month the Apache Infrastructure Team fell victim to a common web application attack. Rather than keep the information secret, they were kind enough to explain how the attack occurred. The initial attack leveraged cross-site scripting to steal users' session IDs. This is something that could have been prevented if the web app's session cookie had been marked with the HttpOnly attribute. When a web app sets a cookie, the presence of HttpOnly instructs browsers to disallow client-side script from accessing the cookie.

You will sometimes hear or read that HttpOnly helps prevent XSS attacks. That is not quite true. It helps prevent session hijacking. Specifically, it helps guard against one attack vector, namely where session cookies are stolen via XSS. HttpOnly can be used for any sensitive cookie that you don't want falling into the hands of fraudsters. (I should use "fraudster" more often - it is a fun word)

There is one caveat to using HttpOnly. It might break your application if it was written in such a way that the functionality depends on JavaScript having access to the cookie. That is fairly uncommon however.gmdavef@gmail.com (Dave Ferguson)06202448387744872480

The British High Court ruled that a software vendor's EULA -- which denied all liability for poor software -- was not reasonable.

I wrote about software liabilities back in 2003.

schneier0386499335783409583012391647509919601250134555894370499844680454090900191520032702536988288782288611124724011587052652781159450432561576296806748650429334202339177973983404698561220503324066241615316812965523811113217219165732555780263118640513227753123957807115977177421606265108010789099119752974430537033376926193527117150462406304581446

Hey Guys

Sorry for such a late post (been busy wid work :( ).....

Recently a friend came to me and told me about a scenario which he had used to deploy his web application. He had built his application using PHP on Apache. There was a front-end server directly accessible to the internet and a back-end server only accessible to the front-end server. The PHP application deployed on the front end server included PHP files kept on the back-end server and showed it on the browser. The included PHP files were hard coded in the code of the PHP application running on the front-end server and this front end application took a GET parameter as input.

Now, this scenario kind of caught my interest. I recently read about HTTP parameter pollution and I thought this attack might work in this case. So I began digging and experimenting. And I came up with a demonstration which shows how will this attack work when someone is using a setup similar to the setup described above to bypass a hard coded value in the code. I know this is not recon stuff ,but still its interesting.. ;)

We will see 4 PHP codes here :-

1.) hpp.php - The main application deployed on the front-end server, which remotely includes a PHP code (cms.php) kept on the back-end server.



2.) cms.php - A PHP code kept on the back-end server which receives an input from hpp.php in the "function" parameter and includes a PHP code (set to normaluser.php) meant for a normal user locally.



3.) normaluser.php - A PHP code kept on the back-end server meant for a normal user and included by cms.php .The ping command was set in this case to show that the normal user can only use the ping service.



4.) adminuser.php - A PHP code meant for an admin user. This code can run any OS command directly to show that this code really is for the admin ;) .



Now, we can see that the normaluser.php and adminuser.php codes are vulnerable to OS command injection and XSS flaws, but I wont discuss them here because they are not the subject we want to talk about right now. This scenario was tested on the same server (my local server), cause I didn't had two servers to make a front-end and a back-end server :) . I used the session variables here to make myself feel like the back-end web applications are really not accessible directly, but only through the front-end web application ;) . The random variable (which is not really random) was chosen just to demonstrate that the "auth" session variable will get set only when cms.php is called by hpp.php and not directly.

Lets talk a little about HPP. HPP i.e. HTTP parameter pollution is an injection attack which consists of injecting query string delimiters and overriding or adding HTTP GET or POST parameters. This attack consists of client side HPP and server side HPP. We are discussing server side HPP here.

Different platforms take multiple HTTP GET, POST or COOKIE parameters with the same name in different ways. In our case, which is PHP on apache, if we provide multiple parameters with the same name to a web application, the application will consider the last parameter with the same name and use that instead of all the other parameters with the same name occurring before it.

Lets move on with the testing part. Opening hpp.php shows us the following:-



Entering an IP and hitting enter shows us the following:-



We can see that the normaluser.php script got included and executed. Lets see what input this application takes using a web proxy:-



We can see that the application takes a POST parameter named "b" which contains the IP we entered.

Now, looking at the hpp.php code and referring back to the discussion we just had about different platforms processing multiple parameters with same names in different ways, if we can make hpp.php take another "function" parameter containing a different PHP application other than normaluser.php, then hpp.php will remotely include cms.php with two "function" parameters in the URL and the one that comes at the last position will be processed by cms.php.

So, how do we go about it.

Open hpp.php and again input an IP and hit enter while intercepting the request using a web proxy as shown:-



Inject a "%26function%3dadminuser.php" after the IP as shown:-



to get the following output:-



All righty!! So what just happened.. It can be clearly seen that this time adminuser.php is included. Basically, "%26function%3dadminuser.php" is equivalent to "&function=adminuser.php"; the only difference being that the query string delimiters have been URL encloded. When we inject "%26function%3dadminuser.php" in the POST parameter, hpp.php URL decodes this value to "&function=adminuser.php" and the final string in the require_once function i.e. $d becomes "http://localhost:8080/cms.php?function=normaluser.php&cmd=127.0.0.1&function=adminuser.php&rand=12345" which consists of two "function" parameters. According to the behavior of PHP, when cms.php is remotely included with these two parameters with the same name (function), cms.php will process the last parameter, and since the value of the last function parameter is "adminuser.php", that file is included and executed.

We know that adminuser.php takes an OS command directly, so all we have to do is replace the IP with an OS command to get the required results as shown:-





So we were able to override a hard coded value in the code with one of our own value to get a file of our choice executed. cooooll!!

In this attack, we already took out all the information from the code needed to perform the attack. And it can be seen, it would have been much difficult to guess exactly what we have to inject in the parameter to get the work done.

I actually never tried this attack on my friend's web application, but it gave me a hint as in how this attack can be so devastating.

Any suggestions and feedbacks are most welcome.

Till we meet again Bbyes :)noreply@blogger.com (Dragunov)06202448387744872480

Yola lets you take online matters into your own hands.

Is it (literally) a priceless tool for tracking and scrutinizing online traffic, or is it too complex for the average entrepreneur? Two readers offer their own analyses.

The Web Container in IBM WebSphere Application Server (WAS) 6.0 before 6.0.2.43, 6.1 before 6.1.0.31, and 7.0 before 7.0.0.11 does not properly handle long filenames and consequently sends an incorrect file in some responses, which allows remote attackers to obtain sensitive information by reading the retrieved file.

The Web Container in IBM WebSphere Application Server (WAS) 6.0 before 6.0.2.43, 6.1 before 6.1.0.31, and 7.0 before 7.0.0.11 does not properly handle chunked transfer encoding during a call to response.sendRedirect, which allows remote attackers to cause a denial of service via a GET request.

Unspecified vulnerability in IBM WebSphere Application Server (WAS) 6.0 before 6.0.2.41, 6.1 before 6.1.0.31, and 7.0 before 7.0.0.11 allows remote attackers to cause a denial of service (memory consumption and daemon crash) via a crafted request, related to the nodeagent and Deployment Manager components.

The (1) JAX-RPC WS-Security 1.0 and (2) JAX-WS runtime implementations in IBM WebSphere Application Server (WAS) 6.0 before 6.0.2.41, 6.1 before 6.1.0.31, and 7.0 before 7.0.0.11 do not properly handle WebServices PKCS#7 and PKIPath tokens, which allows remote attackers to bypass intended access restrictions via unspecified vectors.

Directory traversal vulnerability in aria2 before 1.9.3 allows remote attackers to create arbitrary files via directory traversal sequences in the name attribute of a file element in a metalink file.

KGet 2.4.2 in KDE SC 4.0.0 through 4.4.3 does not properly request download confirmation from the user, which makes it easier for remote attackers to overwrite arbitrary files via a crafted metalink file.

Directory traversal vulnerability in KGet in KDE SC 4.0.0 through 4.4.3 allows remote attackers to create arbitrary files via directory traversal sequences in the name attribute of a file element in a metalink file.

Directory traversal vulnerability in Free Download Manager (FDM) before 3.0.852 allows remote attackers to create arbitrary files via directory traversal sequences in the name attribute of a file element in a metalink file.

Multiple stack-based buffer overflows in Free Download Manager (FDM) before 3.0.852 allow remote attackers to execute arbitrary code via vectors involving (1) the folders feature in Site Explorer, (2) the websites feature in Site Explorer, (3) an FTP URI, or (4) a redirect.

This article will describe how to protect your J2EE application from Cross Site Request Forgery (CSRF/XSRF) attacks using ESAPI. As with all of the detail articles in this series, if you need a refresher on OWASP or ESAPI, please see the intro article The OWASP Top Ten and ESAPI.

What’s the problem?

What is Cross Site Request Forgery (CSRF)? As usual, let’s check in with what OWASP says it is:

“A CSRF attack forces a logged-on victim’s browser to send a request to a vulnerable web application, which then performs the chosen action on behalf of the victim. The malicious code is often not on the attacked site. This is why it is called ‘Cross Site’. ” [from here] Additionally, they give several examples of the types of vulnerable sites including sites that “Authorize requests based only on credentials that are automatically submitted such as the session cookie if currently logged into the application, or ‘Remember me’ functionality if not logged into the application, or a Kerberos token if part of an Intranet participating in integrated logon with Active Directory”. Finally this statement is added: “Unfortunately, today, most web applications rely solely on automatically submitted credentials such as session cookies, basic authentication credentials, source IP addresses, SSL certificates, or Windows domain credentials.”

So, what does all this mean? It means that (most likely) if you aren’t protecting against CSRF, you are vulnerable to it. That’s a scary thought! Many developers don’t even know about the attack (though they should), yet they are vulnerable by default in many instances. It’s a devastating attack to many web applications. Let’s discuss in a bit of detail what it looks like. In my opinion, the easiest way to explain the attack is to walk through it in a series of steps.

1. Bob (User/Victim) logs in (or is already logged in) to “Vulnerable website X”. This website has contains some sort of e-commerce type functionality. It also allows you to store your credit card for future purchases.
2. Mary (Attacker) knows and uses website X and realizes that CSRF is a vulnerability in the application.
3. Mary crafts a bit of html and/or javascript and posts it to a forum/message board that Bob reads (any site on the internet).
The code might look something like this:

<img src="http://www.siteX.com/completePurchase.do?itemId=ABC123" />

4. Bob views the html and/or javascript by visiting the forum (though nothing visible shows up) and the code is executed. Bob has just purchased an item of the attacker's choosing without knowing it.

Ok, a few things to note about the sequence above.
a. The vulnerable site doesn't have to be e-commerce. It could be credit card related info, or adding a friend to your group. For the most part, it has to do with transactions. Usually, it's not a big deal on "view" type pages.
b. The forum/message board, while common, is not the only way to cause this. It could be done through an email, or any other number of attack vectors.
c. The actual attack here was fairly benign, but be certain, there are more nefarious attacks that exist, and are executed all the time.

Ok, so hopefully you are sufficiently concerned now based on the description above.

Where do we go from here? ....

So, now we understand what can happen if a site is vulnerable to CSRF (and most are), but what how do we solve that problem. Well, simply put, we have to have a way to know that the request is legitimate, meaning that the user intended to make the request. The most common mechanism in place today (that works) is the token. The token is a generic term that is used for implementations of the "synchronizer token pattern". There are several working implementations that use the token today, including Struts 1 and 2, Webwork, SpringMVC, and even OWASP's own CSRFGuard Project. However, since we're discussing the usage of ESAPI to solve the OWASP Top Ten, we'll cover how ESAPI does it in this article.

At this point, CSRF is actually pretty easy to solve. We know what the issue is, know how to solve it, and have a framework (ESAPI) that will help with the specifics. So, here are the steps we'll actually go through in order to protect our apps from CSRF attacks.
1. Generate new CSRF token and add it to user once on login and store user in http session.
2. On any forms or urls that should be protected, add the token as a parameter / hidden field.
3. On the server side for those protected actions, check that the submitted token matches the token from the user object in the session. (Assuming you've implemented this properly, a failure constitutes a security issue.)
4. On logout and session timeout, the user object is removed from the session and the session destroyed.

Now that we have the steps, we'll give a short snippet of code that shows each in action.

Step 1. Generate new CSRF token and add it to user once on login and store user in http session.
This code should be executed when the user logs into the application. This is done in the default ESAPI implementation, and it is stored as a member variable of the User object that gets stored in the session.

//this code is in the DefaultUser implementation of ESAPI /** This user's CSRF token. */ private String csrfToken = resetCSRFToken(); ... public String resetCSRFToken() { csrfToken = ESAPI.randomizer().getRandomString(8, DefaultEncoder.CHAR_ALPHANUMERICS); return csrfToken; }

Step 2. On any forms or urls that should be protected, add the token as a parameter / hidden field.
The addCSRFToken method below should be called for any url that is going to be rendered that needs CSRF protection. Alternatively if you are creating a form, or have another technique of rendering URLs (like c:url), then be sure to add a parameter or hidden field with the name "ctoken" and the value of DefaultHTTPUtilities.getCSRFToken(). That should do the work of adding the data to the url or form. We'll validate it in the next step.

//from HTTPUtilitiles interface final static String CSRF_TOKEN_NAME = "ctoken"; //this code is from the DefaultHTTPUtilities implementation in ESAPI public String addCSRFToken(String href) { User user = ESAPI.authenticator().getCurrentUser(); if (user.isAnonymous()) { return href; } // if there are already parameters append with &, otherwise append with ? String token = CSRF_TOKEN_NAME + "=" + user.getCSRFToken(); return href.indexOf( '?') != -1 ? href + "&" + token : href + "?" + token; } ... public String getCSRFToken() { User user = ESAPI.authenticator().getCurrentUser(); if (user == null) return null; return user.getCSRFToken(); }

Step 3. On the server side for those protected actions, check that the submitted token matches the token from the user object in the session. (Assuming you've implemented this properly, a failure constitutes a security issue.)
Ensure that you call this method from your servlet or struts action or jsf controller, or whatever server side mechanism you're using to handle requests. This should be called on any request that you need to validate for CSRF protection. Notice that when the tokens do not match, it's considered a possible forged request.

//this code is from the DefaultHTTPUtilities implementation in ESAPI public void verifyCSRFToken(HttpServletRequest request) throws IntrusionException { User user = ESAPI.authenticator().getCurrentUser(); // check if user authenticated with this request - no CSRF protection required if( request.getAttribute(user.getCSRFToken()) != null ) { return; } String token = request.getParameter(CSRF_TOKEN_NAME); if ( !user.getCSRFToken().equals( token ) ) { throw new IntrusionException("Authentication failed", "Possibly forged HTTP request without proper CSRF token detected"); } }

Step 4. On logout and session timeout, the user object is removed from the session and the session destroyed.
In this step, logout is called. When that happens, note that the session is invalidated and the current user object is reset to be an anonymous user, thereby removing the reference to the current user and accordingly the csrf token.

//this code is in the DefaultUser implementation of ESAPI public void logout() { ESAPI.httpUtilities().killCookie( ESAPI.currentRequest(), ESAPI.currentResponse(), HTTPUtilities.REMEMBER_TOKEN_COOKIE_NAME ); HttpSession session = ESAPI.currentRequest().getSession(false); if (session != null) { removeSession(session); session.invalidate(); } ESAPI.httpUtilities().killCookie(ESAPI.currentRequest(), ESAPI.currentResponse(), "JSESSIONID"); loggedIn = false; logger.info(Logger.SECURITY_SUCCESS, "Logout successful" ); ESAPI.authenticator().setCurrentUser(User.ANONYMOUS); }

So there you have it. Not very complex, but solid protection against CSRF. In quick review, we covered what CSRF is, why it's a problem, and how to solve it using 4 simple steps (create token, add token to forms/urls, verify token server side, kill token on logout). There are a couple of additional notes I wanted to point out.

Note: In addition to resolving the CSRF issues in your application, you also need to resolve the XSS issues in your application (see The OWASP Top Ten and ESAPI - Part 2 - Cross Site Scripting (XSS)). If those still exist, the CSRF defenses can be circumvented.

For some additional background and information on CSRF, see the OWASP CSRF Prevention Cheat Sheet.

Well, that's it. Hope you've found this article helpful. Let me know if you have any questions or suggestions. Feel free to comment on techniques you are using to correct CSRF and if you've seen it as a large problem for your applications.

Other articles in this series:
Part 1: The OWASP Top Ten and ESAPI
Part 2: The OWASP Top Ten and ESAPI - Part 2 - Cross Site Scripting (XSS)
Part 3: The OWASP Top Ten and ESAPI - Part 3 - Injection Flaws
Part 4: The OWASP Top Ten and ESAPI - Part 4 - Malicious File Execution
Part 5: The OWASP Top Ten and ESAPI - Part 5 - Insecure Direct Object Reference

Technorati Tags: Cross Site Request Forgery, ESAPI, J2EE, Java, OWASP, Security, Validation

Shared by Jeff Williams
Awesome! Establishing a Kenyan chapter of OWASP Awesome!

I’ve just finished a job where I used OWASP’s Application Security Verification Standard as a light weight security architecture template.

The good news is that it helped us decide a bunch of controls (using ESAPI of course) that will hopefully improve the security of the application. I’ll find out in a few months if any of it helped.

What worked: pretty much everything.

What didn’t work: Some controls are not relevant to some classes of application. Do your homework before you go into the meeting so you can skip over ASVS controls that simply can’t work.

We found that there are controls we discussed that aren’t in the ASVS. The ASVS is a 80%/20% (Pareto principle) standard as pretty much all apps come from such a low basis today, so any security improvement is a worthwhile improvement even if it’s not milspec. I wasn’t too fussed that we missed a few key items.

For those of you floundering around trying to figure out how to do Security Architecture reviews, ASVS can be your friend!

W3C is pleased to announce the creation of the Audio Incubator Group, whose mission is to explore the possibility of starting one or more specifications dealing with various aspects of advanced audio functionality, including reading and writing raw audio data,... W3C Staff

For some hackers, stealing your data isn't enough. Use these tips to keep them from taking control.

The content management system--the powerful, behind-the-scenes operator--can make or break your site. Here's how to choose the right one.