KeepItLocked.net - All Comments

Checking for ViewStateUserKey using FxCop

Sacha Faust Web Security Blog — Thu, 25 Sep 2008 22:43:11 GMT

ASP.NET has had a mitigation to prevent against CSRF/One-Click attacks since 1.1 with the use of Page.ViewStateUserKey

re: Giving the OWASP .NET ESAPI a Second Look

ilivewithian — Wed, 10 Sep 2008 10:58:00 GMT

You talk about a web.config file that is secure by default. Is there one on the web somewhere that I could use for reference?

Thanks,

Rob

Giving the OWASP .NET ESAPI a Second Look

KeepItLocked.net — Wed, 10 Sep 2008 01:20:27 GMT

I've started up work again on the OWASP .NET ESAPI . Since a few months ago, when I translated the OWASP

re: A Brief History of Applet Security

trond — Fri, 22 Aug 2008 20:56:58 GMT

No change as of august 2008.

The certificate warning is almost a joke and it is in badly need of a redesign to warn users of how much access you actually give the Java applet. I'd really like to use this for single file load/save, but I'm not comfortable recommending it to users. I'd prefer lower-level security access by a file-dialog that's in control by the user, as handled in browsers, but without having to perform a submit against the server.

re: Goofus and Gallant, Part One

Alex — Wed, 11 Jun 2008 20:33:50 GMT

I've been notified that this diagram is actually a little confusing. The “certificate” coming from the session store was actually meant to be a representation of a user name, or other form of identity, in the session. The goal was to point out that you shouldn’t accept the user name directly from the user. Instead, you should accept a session identifier, which you correlate with a user ID in the session store.

re: Java and HttpOnly

Alex — Wed, 28 Nov 2007 22:13:16 GMT

Yes, indeed the code shown does work. After the chain.doFilter(), the response has already been sent to the client, so the response modification needs to occur before.

From "The Essentials of Filters"

java.sun.com/.../Filters.html

<quote>

The most important method in the Filter interface is the doFilter method, which is the heart of the filter. This method usually performs some of the following actions:

* Examines the request headers

* Customizes the request object if it wishes to modify request headers or data or block the request entirely

* Customizes the response object if it wishes to modify response headers or data

* Invokes the next entity in the filter chain. If the current filter is the last filter in the chain that ends with the target servlet, the next entity is the resource at the end of the chain; otherwise, it is the next filter that was configured in the WAR. It invokes the next entity by calling the doFilter method on the chain object (passing in the request and response it was called with, or the wrapped versions it may have created). Alternatively, it can choose to block the request by not making the call to invoke the next entity. In the latter case, the filter is responsible for filling out the response.

* Examines response headers after it has invoked the next filter in the chain

* Throws an exception to indicate an error in processing

</quote>

As far as calling request.getSession(), I believe that this must have already been called in a previous filter.

re: Java and HttpOnly

owasp — Tue, 06 Nov 2007 10:38:23 GMT

Does this really work? If the call to request.getSession() hasn't happened yet, then the response won't have the set-cookie header yet. Seems to me that the call to chain.doFilter() should come before the set-cookie check so the response will be filled in.

Securing ActiveX Controls

codesecurely.org — Wed, 17 Oct 2007 04:20:09 GMT

I was reading my buddy Alex Smolen's post the other day on Java Applet Security and figured I would see