<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Week of War on WAF&#8217;s: Day 5 &#8212; Final thoughts</title>
	<atom:link href="http://www.tssci-security.com/archives/2008/06/27/week-of-war-on-wafs-day-5-final-thoughts/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.tssci-security.com/archives/2008/06/27/week-of-war-on-wafs-day-5-final-thoughts/</link>
	<description>top secret/secure computing information</description>
	<lastBuildDate>Thu, 01 Apr 2010 15:34:41 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Antonio</title>
		<link>http://www.tssci-security.com/archives/2008/06/27/week-of-war-on-wafs-day-5-final-thoughts/comment-page-1/#comment-8294</link>
		<dc:creator>Antonio</dc:creator>
		<pubDate>Mon, 30 Jun 2008 17:39:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.tssci-security.com/archives/2008/06/27/week-of-war-on-wafs-day-5-final-thoughts/#comment-8294</guid>
		<description>On this whole &#039;acting on application output only&#039; idea.  How would that protect against &#039;second order&#039;  attacks?  For example injecting code into an application that will attack a different application later?  Wouldn&#039;t you have to act on input to &#039;protect&#039; against that (arguments on whether WAFs are a good idea aside).</description>
		<content:encoded><![CDATA[<p>On this whole &#8216;acting on application output only&#8217; idea.  How would that protect against &#8217;second order&#8217;  attacks?  For example injecting code into an application that will attack a different application later?  Wouldn&#8217;t you have to act on input to &#8216;protect&#8217; against that (arguments on whether WAFs are a good idea aside).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: MikeA</title>
		<link>http://www.tssci-security.com/archives/2008/06/27/week-of-war-on-wafs-day-5-final-thoughts/comment-page-1/#comment-8196</link>
		<dc:creator>MikeA</dc:creator>
		<pubDate>Sat, 28 Jun 2008 15:12:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.tssci-security.com/archives/2008/06/27/week-of-war-on-wafs-day-5-final-thoughts/#comment-8196</guid>
		<description>Great, great series of posts guys. 

When you say that I&#039;m &quot;very set on the idea that WAF (with proper blacklists) or VA+WAF (to manage the blacklists) are fair enough temporary solutions until organizations can implement secure coding&quot; I guess that is in some way true, but misses my point.

What I&#039;m trying to say, perhaps badly, is that WAFs are not totally worthless - there is some benefit in them, which mostly seems to be ignored.  Sure, they are no silver bullet, but neither are they a box/plugin that does nothing - it&#039;s all in the way they they are used/operated. I don&#039;t believe that it&#039;s a zero-sum game.  Are there issues with them - totally - but they are new(ish) technology, and are inevitably going to go through growing pains just as all software does.  I don&#039;t have any any investment either sides of the argument, so I guess I would like to see how this plays out over time and would hate to see a technique/technology simply dismissed because it it&#039;s perfect &quot;out the gate&quot;.

This is just from a researcher/technologist point of view though - if I were an IT guy/CISO/etc, I probably would have a different viewpoint.

I whole-heartedly agree that it&#039;s much better to do validation, etc, closer (within) the code - there&#039;s much better &quot;context&quot; to know what to do.  Programmers are human though, and will make mistakes/omissions - we therefore need a way to help protect these holes after-the-fact.  Be that dynamic patching, technology like WAFs,  or &quot;something else&quot;, for me the jury is still out but the need is still there.</description>
		<content:encoded><![CDATA[<p>Great, great series of posts guys. </p>
<p>When you say that I&#8217;m &#8220;very set on the idea that WAF (with proper blacklists) or VA+WAF (to manage the blacklists) are fair enough temporary solutions until organizations can implement secure coding&#8221; I guess that is in some way true, but misses my point.</p>
<p>What I&#8217;m trying to say, perhaps badly, is that WAFs are not totally worthless &#8211; there is some benefit in them, which mostly seems to be ignored.  Sure, they are no silver bullet, but neither are they a box/plugin that does nothing &#8211; it&#8217;s all in the way they they are used/operated. I don&#8217;t believe that it&#8217;s a zero-sum game.  Are there issues with them &#8211; totally &#8211; but they are new(ish) technology, and are inevitably going to go through growing pains just as all software does.  I don&#8217;t have any any investment either sides of the argument, so I guess I would like to see how this plays out over time and would hate to see a technique/technology simply dismissed because it it&#8217;s perfect &#8220;out the gate&#8221;.</p>
<p>This is just from a researcher/technologist point of view though &#8211; if I were an IT guy/CISO/etc, I probably would have a different viewpoint.</p>
<p>I whole-heartedly agree that it&#8217;s much better to do validation, etc, closer (within) the code &#8211; there&#8217;s much better &#8220;context&#8221; to know what to do.  Programmers are human though, and will make mistakes/omissions &#8211; we therefore need a way to help protect these holes after-the-fact.  Be that dynamic patching, technology like WAFs,  or &#8220;something else&#8221;, for me the jury is still out but the need is still there.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
