Just a quick note I've been meaning to post about a small bug in Chris Pederick's Firefox Web Developer extension. It is a fantastic extension and I use it all the time, especially for working with cookies. Kudos to Mr. Pederick!
Unfortunately, what I noticed is that if you have "accept third-party cookies" unchecked in Firefox's privacy options, you can't edit cookies or add cookies. In fact it ends up deleting the cookies that you try to edit. D'oh!
This bug bit me a few times when I was trying to demonstrate session hijacking while teaching an application security class. This bug is a known issue and I'm hoping Chris can find a way to make it work in the next version. In the meantime, I will keep using the extension and trying to remember to enable third-party cookies whenever I teach the class.
Friday, May 28, 2010
Monday, May 17, 2010
A Case for HttpOnly
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.
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.
Wednesday, May 12, 2010
Dynamically-Generated PDFs
Many web applications will generate PDF files for users so they can view nicely-formatted statements, reports, etc. These dynamically-generated PDFs are typically accessed by users in two different ways.
1) The application creates an actual PDF file on the server and redirects the user's browser to the file (via 302 response code).
2) The application streams the bytes for the PDF directly to the user's browser as part of the HTTP response.
This second method is much more secure. The reason is that a PDF file sitting on a server can probably be accessed by anyone. The only information needed is the directory and the file name. That said, I have seen the first method implemented securely, but two important mitigating factors were employed. First, the application used randomized file names. A globally-unique identifier (GUID) is great for this. Second, the files were deleted within about 10 seconds of them being created. These two factors, when combined, made it almost impossible to gain access to another user's PDF file.
Testing for this vulnerability is simple. If you run across an application that allows you to download a dynamic PDF, make note of the URL when viewing the PDF. Is it a direct link to the PDF file? If so, copy the link, open a different browser (not another window of the same browser), and paste the URL. Is the PDF loaded? If so, then you have a problem, especially if the file name is guessable or follows a pattern. You might also check to see if the PDF is deleted from the server after a time.
This topic applies to other static files that your application might generate dynamically too, such as Excel files. PDFs just seem to be the most common.
1) The application creates an actual PDF file on the server and redirects the user's browser to the file (via 302 response code).
2) The application streams the bytes for the PDF directly to the user's browser as part of the HTTP response.
This second method is much more secure. The reason is that a PDF file sitting on a server can probably be accessed by anyone. The only information needed is the directory and the file name. That said, I have seen the first method implemented securely, but two important mitigating factors were employed. First, the application used randomized file names. A globally-unique identifier (GUID) is great for this. Second, the files were deleted within about 10 seconds of them being created. These two factors, when combined, made it almost impossible to gain access to another user's PDF file.
Testing for this vulnerability is simple. If you run across an application that allows you to download a dynamic PDF, make note of the URL when viewing the PDF. Is it a direct link to the PDF file? If so, copy the link, open a different browser (not another window of the same browser), and paste the URL. Is the PDF loaded? If so, then you have a problem, especially if the file name is guessable or follows a pattern. You might also check to see if the PDF is deleted from the server after a time.
This topic applies to other static files that your application might generate dynamically too, such as Excel files. PDFs just seem to be the most common.
Subscribe to:
Posts (Atom)