Hi Chris, The crunch of your argument: >I would argue that your data protection should occur at the business >layer. ... >Adding a single layer of "security" should not be considered a >replacement for code and security reviews, unit testing, and user-level >testing.
Unfortunately, you did not understand or have missed the point... its not about forgoing coded checks, the key point here is to manage data security in a more efficient way. >Really? I wasn't aware that converting '<' to < was that much of a >bottleneck. You naively assume the vendors point of view here, encoding output is not always sufficient! >> data is now more complex >Is it? The same attack vectors exist today than did several years ago, >and the mitigations for those vectors are still the same. Are you kidding? If you cannot see this then there is little point to this discussion and so many projects out there are simply a waste of time! Peter ----- Original Message ----- From: "Christopher Schultz" <[EMAIL PROTECTED]> To: "Tomcat Users List" <users@tomcat.apache.org> Sent: Tuesday, 27 May, 2008 9:27:33 PM GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Code Injection Tomcat 6 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter, Peter Stavrinides wrote: | The one problem though is that these arcane methods we have been | using (encoding output, coding some validation checks, using prepared | statements etc..) are not scalable enough Really? I wasn't aware that converting '<' to < was that much of a bottleneck. In fact, this is certainly scalable because if you think it's taking too much time on a single server, you can scale horizontally. | data is now more complex Is it? The same attack vectors exist today than did several years ago, and the mitigations for those vectors are still the same. | new technologies (AJAX,COMET,JSON,SOAP etc) are adding layers, and | add significantly to the problem. I respectfully disagree. A new interface (i.e. swapping SOAP for HTTP) should not change your business logic in the slightest (which is where any taint checking should occur). The same is true for presentation logic: if you are using SOAP, yous SOAP library ought to be converting any output such that special characters (such as '<') are not dangerous. The same can be said for web-page generation. If you are emitting web pages, then your output technology should handle this for you (JSP, for instance, does handle this for you if you follow the rules). Adding a single layer of "security" should not be considered a replacement for code and security reviews, unit testing, and user-level testing. | Preventing data interception is not | so straightforward any more, without something available at the web | server end of things, any security solutions we implement will always | have holes and scalability issues. I would argue that your data protection should occur at the business layer, which should be insulated from the HTTP layer in the first place. In that case, installing a prophylactic at the HTTP level would expose your business logic to vectors that do not include HTTP (such as COMET or SOAP). | Security is somewhat of a moving | target, I think we have to move on from these techniques... only when | you have experienced a problem, do you feel compelled to give it the | attention it requires. My query is not based on paranoia, I want a | better way of managing the problem in the enterprise. Actually, in this situation, paranoia is your friend. It's a good motivator to review your systems to make sure that they react properly when given potentially damaging inputs. That's what unit testing is for. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkg8UpUACgkQ9CaO5/Lv0PAklgCgvBeaMpQsc+U1dqRTlwKES06t xE8AmwV2YNKNWPxfJzECrsBT9KrsR0qY =bc6/ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
