which security breach does your algorithm seek to detect or prevent..
HTML/JavaScript code injection?
http://aranea.zuavra.net/index.php/66/#ig-4
?
Martin-
----- Original Message -----
From: "Peter Stavrinides" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <users@tomcat.apache.org>
Sent: Thursday, May 29, 2008 5:58 AM
Subject: Re: Code Injection Tomcat 6
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]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
