John Melton's Weblog - Latest Comments

Re: Year Of Security for Java – Week 19 – Reduce the Attack Surface

jtmelton — Thu, 10 May 2012 18:23:42 -0000

Jim, I deeply enjoy hearing your thoughts and comments about pretty much everything. You are clearly a very sharp guy, and your writing expresses that.

That said, I only partially agree with your comments. Reducing attack surface is absolutely about entry points, whether urls, apis, etc. as you pointed out. In the past I've been bitten by all of these issues as it relates to reducing attack surface.
You agreed that #4 and #5 have relevance, so I won't belabor those.

For #1 (dead code), I certainly could have done a better job at pointing out the relationship with attack surface. What I've seen in the past is someone enable dead/commented code thinking maybe that's the reason why some bug they were dealing with was happening. They then fix the bug, and now the "dead" code is live and accessible as a new(old) entry point. This is certainly a tenuous leap, but one I've seen repeatedly. Luckily we caught many of these through code review, but other groups might not have appropriate processes in place, so I pointed it out here. Your points here are definitely well taken though - I could've done a much better job describing these.

For #2, (copied code), I've definitely seen this happen a lot w/ junior developers. They copy a bit of code not knowing that they're opening up a new entry point. Say, they've copied code that has a springmvc annotation on it for instance. That's automatically a new entrypoint. This is a particularly egregious example, but I've certainly seen things like this happen repeatedly, whether copying code or configuration.

For #3 (extra features), This is an area where the issue is probably clear. A dev builds some extra thing-a-ma-bob into the app for the "wow" of the end user. It's pretty, but also adds to the attack surface unnecessarily.

I hope I've given a little clarity to the issues you brought up. Thanks for pointing them out!

Re: Year Of Security for Java – Week 19 – Reduce the Attack Surface

Jim Bird — Thu, 10 May 2012 17:27:48 -0000

A lot of this is good advice. But not a lot of it has to do with reducing the attack surface of the application. The attack surface is the total of the entry points that an attacker can possibly use to attack the application: sockets, URLs, APIs, files, external databases, etc. Understanding this and protecting these entry points (and reducing them where possible) is what managing the attack surface should be about.

Nothing that you are saying here is bad advice by any means, but this discussion seems to be more about lean development than attack surface management except for #5 "extra services enabled" which is about turning off stuff you don't need in third party apps (application hardening) and maybe #4 not including code in libraries that you don't necessarily need (although this is easier said than done).

For example, dead code can't be attacked - it is after all dead. It's good to get rid of it for other reasons, but reducing the attack surface isn't one of them.

One of the ways to reduce the attack surface of an app as you point out in #5 is to turn off features - therefore you shouldn't have to get rid of code that is disabled through configuration, unless the way that you have done it is naive (like "disabling" the feature only by not showing access at the client but still leaving the path open on the server). Again, there are good reasons to get rid if this code if you know you aren't going to use it, to simplify maintenance and testing and so on, but you've already reduced the attack surface by disabling the option. Copied code is often a bad idea, but again doesn't necessarily have to do with attack surface management.

Re: Year Of Security for Java – Week 15 – Audit Security Related Events

Alexis FitzGerald — Wed, 11 Apr 2012 08:53:28 -0000

Excellent series.

Section 4.3 of the PCI Payment Application Data Security Standard(*) gives an overview of the type of data that should be stored as part of an audit trail.
(*)https://www.pcisecuritystandar...

Re: The OWASP Top Ten and ESAPI – Part 2 – Injection Flaws

Nareerat Preechakorn — Mon, 05 Mar 2012 22:54:07 -0000

Thank you John , very helpful ^^

Re: Year Of Security for Java – Week 7 – Content Security Policy

Will Stranathan — Wed, 29 Feb 2012 07:29:39 -0000

I seriously wish other browsers would begin to implement CSP. Unfortunately, right now, only Firefox supports it. One day.

WRT event handlers, you can't use the onWhatever handlers, but adding them is simple enough - document.getElementById('foo').click = function() { ... }.

Re: Year Of Security for Java – Week 6 – CSRF Prevention in Java

jtmelton — Wed, 08 Feb 2012 09:54:46 -0000

Stephen de Vries Good point. There are certain frameworks that do this, some better than others. My understanding is that one of the most successful is Django from the Python world.

Re: Year Of Security for Java – Week 6 – CSRF Prevention in Java

Stephen de Vries — Wed, 08 Feb 2012 04:39:13 -0000

I thought it was cute that you sometimes get CSRF protection for free when using some web frameworks. For example Spring Webflow uses a flowId value to keep track of a flow within a session and it's attached to every request that's part of a flow. So automatic CSRF protection.
JBoss Seam has a similar mechanism for it's "conversations" concept, but from what I remember the value was an incrementing numeric value - so not ideal for anti CSRF token.

Re: The OWASP Top Ten and ESAPI – Part 9 – Insecure Communications

john — Wed, 21 Sep 2011 15:13:34 -0000

@Charles,
I honestly don't remember if there is a config option in the ESAPI.properties file (though that's where you need to check) related to https. However, you can always override the check (probably search for assertSecure in the ESAPI code) in your own implementation.

Re: The OWASP Top Ten and ESAPI – Part 9 – Insecure Communications

Charles — Wed, 21 Sep 2011 14:26:47 -0000

Okay... but what if you WANT to use HTTP? The Swingset demo and apache server are HTTP, and none of the pages in the demo work because of that. How do I disable the HTTPS requirement in ESAPI so I can run these samples?

Re: The OWASP Top Ten and ESAPI – Part 1 – Cross Site Scripting (XSS)

john — Wed, 21 Sep 2011 01:02:53 -0000

@Charles,
Yes you can look at the esapi-dev and esapi-user mailing lists (and their archives). Thought it's not a standard forum, it's the mechanism you can use to get info. I'd start w/ the user list first.

Re: The OWASP Top Ten and ESAPI – Part 1 – Cross Site Scripting (XSS)

Charles — Tue, 20 Sep 2011 20:10:40 -0000

Is there a forum for ESAPI? I need to disable strong password checks, and the complete lack of documentation is daunting.

Re: A Simple Multi-Threaded Java HTTP Proxy Server

João Cortela — Thu, 25 Aug 2011 20:32:01 -0000

Thanks man!

Now it's working... =)

It helped me a lot!

Re: A Simple Multi-Threaded Java HTTP Proxy Server

john — Thu, 25 Aug 2011 20:21:59 -0000

@Joao,
Looks like you might not have the java command right. You might want to try "java -cp . proxy.ProxyServer"

Re: A Simple Multi-Threaded Java HTTP Proxy Server

João Cortela — Thu, 25 Aug 2011 20:09:19 -0000

Dude, i'm trying to run your proxy but it fails.
When I compile it with "javac *.java" everything goes OK but when I run "java ProxyServer" i get this error:

"Exception in thread "main" java.lang.NoClassDefFoundError: ProxyServer (wrong name: proxy/ProxyServer)"

Could you help me?
Thanks man!

ps: Sorry for my english (=

Re: The OWASP Top Ten and ESAPI – Part 2 – Injection Flaws

john — Wed, 16 Mar 2011 06:13:36 -0000

@Ram
Thanks for the kind words. Glad you found it helpful

Re: The OWASP Top Ten and ESAPI – Part 2 – Injection Flaws

Ram Guduputi — Wed, 16 Mar 2011 04:42:41 -0000

What an excellent technical details on OWASP issues. This is the best place to learn about Application Security especially J2EE application.

Please continue writing such articles to help your fellow professionals.

Re: Preventing Log Forging in Java

john — Wed, 09 Mar 2011 15:51:34 -0000

@Eric,
Yep, this is a good point. I generally see this more related to restricting the size of your input. If you have length restrictions on incoming data that you are logging (request parms, headers, data from DB, etc.), then you are probably ok. However, you could certainly take the route of limiting the length of every log entry. The issue there is that an attacker could fill to your limit with a few fields, and the remainder (where the actual attack might be) might not get logged. I think individual restrictions on field length is probably a safer route to go, given that logs can be used forensically, so you probably don't want to lose some of that important data. Nice catch though.

Re: Preventing Log Forging in Java

Eric — Wed, 09 Mar 2011 15:39:13 -0000

Sorry for dredging up a post from October...but I wanted to comment on another log forging case. What about a size limit on the amount of input data? Blocking CR/LF is good, but I think that being able to fill the log files with useless characters could also be an attack vector. Not very stealthy, but could be useful.

Re: A Simple Multi-Threaded Java HTTP Proxy Server

john — Fri, 18 Feb 2011 04:47:51 -0000

@Gareth, glad it helped.
@Ngoc, I wrote the example to be very simple and only support GET requests intentionally to show what it takes. There are certainly ways to make this work for POST, but that would take more work, and I'll leave that up to you as I mentioned in the article. You could also just download one of many free http proxy tools that are much more functional.

Re: A Simple Multi-Threaded Java HTTP Proxy Server

Ngoc — Fri, 18 Feb 2011 04:37:24 -0000

Hi John,

The code works for GET requests only.
How to make this work for other request, such as POST?

Tx.
Ngoc

Re: The OWASP Top Ten and ESAPI – Part 1 – Cross Site Scripting (XSS)

john — Tue, 01 Feb 2011 14:31:00 -0000

@Giriraj
That's pretty much right. However, I will point out that it doesn't necessarily mean that you must use a different tag library, though that is an option, and ESAPI does have good output encoding libraries via ESAPI.encoder()... Many of the struts tags do provide sufficient html entity output encoding (by far the most popular output context). In the end, you just have to think about where the data is going and see if the protection is good enough.

XSS is rather simple to solve in *most* cases that I see (though that's just the examples I see), but can be difficult to solve in others, especially in cases where you put data into locations that process url and or javascript content, because browsers often try to "help" and will actually process multiple contexts at once, so you may have to end up wrapping multiple contexts like javascriptencode(urlencode(data)), or something along those lines.

Re: The OWASP Top Ten and ESAPI – Part 1 – Cross Site Scripting (XSS)

Giriraj — Tue, 01 Feb 2011 11:52:50 -0000

Thanks a lot John,

I think I am getting a feel of what this is all about.

I can do validation in conjunction with Struts validator.(that's what we use)
As for output escaping/encoding I guess the best approach would be to change tag libraries and depending upon the 5 different contexts mentioned in the Prevention Cheat Sheet, start using encoding scheme selectively.

I thought it would be straightforward but it isn't. I would have to deviate from the usual developer's mentality.

What do you think?

Thanks again for your time...
Giriraj.

Re: The OWASP Top Ten and ESAPI – Part 1 – Cross Site Scripting (XSS)

john — Fri, 28 Jan 2011 14:40:13 -0000

@GirirajNo
Thanks for the comment.
As for how to implement output encoding, the general recommendation is to put it where your output is actually being rendered, so yes, that's typically done in a jsp, whether it's in a tag or a scriplet or something like that. Struts (1 and 2), SpringMVC, and other web frameworks have tags that usually do encoding (though not all of their tags do) that is sufficient for the html entity context, but nothing more.

As for context I really can't describe it any better than the cheatsheet - so see http://www.owasp.org/index.php.... In short though, it just means the browser interprets the text differently depending on whether your between, say a <p> tag versus if you're between <script> tags.

I suppose a filter could be used to do output encoding via some parsing of the response or something along those lines, but it's much more likely that it would be used for something like input validation. Something like checking all inputs (parameters, headers, etc) against some whitelist character set and for length might get you where you need to go, but that's often not complete, because there will almost always be business requirements that force exceptions to that validation for proper usage of the app.

As to your last point, I certainly understand where you are coming from. Development has been separate from security for a long time in the mind of most developers. Some in the educational system are trying to change that, and folks at owasp (and other groups that provide some sort of training/education) are trying as well, but it's a long road ahead. I do know, however, learning the security piece well will make you a generally better developer, so it's a worthy thing to spend your efforts on.

Re: The OWASP Top Ten and ESAPI – Part 1 – Cross Site Scripting (XSS)

Giriraj — Fri, 28 Jan 2011 10:46:40 -0000

Hey John,

It's a great article.

I have a query regarding output encoding.
How do i go about implementing it our J2EE application?
I mean do I need to use tags to use escaping in all of the jsps that we have?
And I still quite don't understand "context"?

Or can i use a filter to achieve escaping?

Gosh, development seems to be the easier part. Securing the application is altogether different paradigm.

Thanks,
Giriraj.

Re: A Simple Multi-Threaded Java HTTP Proxy Server

Gareth — Fri, 14 Jan 2011 17:46:26 -0000

Dear John,

Thank you for the example. I'd been trying lots of things for ages to get my code working.

Ta,

Gareth