<?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"
	>
<channel>
	<title>Comments on: CORE GRASP - PHP Web Application Protection Software</title>
	<atom:link href="http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/</link>
	<description>Ethical Hacking, Penetration Testing &#38; Computer Security</description>
	<pubDate>Thu, 04 Dec 2008 16:28:24 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.5</generator>
		<item>
		<title>By: Ofer Shezaf</title>
		<link>http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-73043</link>
		<dc:creator>Ofer Shezaf</dc:creator>
		<pubDate>Thu, 15 Nov 2007 03:22:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-73043</guid>
		<description>@fazed: while I would be the 1st to tell you that no security solution, including a WAF is perfect, I think that your example is not relevant. 

First, if this is the risk you forecast in your application, you can easily write a rule to prevent it - just detect base64 (detecting long strings without spaces would do the work). Saying that, avoiding use of HTTP as a hidden channel between two points controlled by the bad guys is very very difficult.

The strength of ModSecurity is that it can do whatever you want it to. The Core Rule Set, which is one example of such a use, does provide a pretty good solution for the problems it tries to address within its design limitations, namely: minimum false positives and minimal configuration.</description>
		<content:encoded><![CDATA[<p>@fazed: while I would be the 1st to tell you that no security solution, including a WAF is perfect, I think that your example is not relevant. </p>
<p>First, if this is the risk you forecast in your application, you can easily write a rule to prevent it - just detect base64 (detecting long strings without spaces would do the work). Saying that, avoiding use of HTTP as a hidden channel between two points controlled by the bad guys is very very difficult.</p>
<p>The strength of ModSecurity is that it can do whatever you want it to. The Core Rule Set, which is one example of such a use, does provide a pretty good solution for the problems it tries to address within its design limitations, namely: minimum false positives and minimal configuration.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ofer Shezaf</title>
		<link>http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-73041</link>
		<dc:creator>Ofer Shezaf</dc:creator>
		<pubDate>Thu, 15 Nov 2007 03:15:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-73041</guid>
		<description>@dre: Fortify hooks to the application. SecureSphere does not.</description>
		<content:encoded><![CDATA[<p>@dre: Fortify hooks to the application. SecureSphere does not.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: CORE GRASP para PHP at Share the information</title>
		<link>http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-72117</link>
		<dc:creator>CORE GRASP para PHP at Share the information</dc:creator>
		<pubDate>Wed, 07 Nov 2007 14:14:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-72117</guid>
		<description>[...] Fuente: Darknet [...]</description>
		<content:encoded><![CDATA[<p>[...] Fuente: Darknet [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dre</title>
		<link>http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-71607</link>
		<dc:creator>dre</dc:creator>
		<pubDate>Wed, 31 Oct 2007 06:18:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-71607</guid>
		<description>@fazed: hence why i was recommending fortifysoftware defender or imperva securesphere over mod_security - they go a little further by hooking into your application.

of course, no WAF will ever stop many complex business logic flaws, session management issues - e.g. CSRF</description>
		<content:encoded><![CDATA[<p>@fazed: hence why i was recommending fortifysoftware defender or imperva securesphere over mod_security - they go a little further by hooking into your application.</p>
<p>of course, no WAF will ever stop many complex business logic flaws, session management issues - e.g. CSRF</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dre</title>
		<link>http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-71606</link>
		<dc:creator>dre</dc:creator>
		<pubDate>Wed, 31 Oct 2007 06:17:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-71606</guid>
		<description>@fak3r: read the last link i provided to "web security gateway" or just go to the mod_security website.

there's also tons of other resources such as &lt;a href="http://www.apachesecurity.net" rel="nofollow"&gt;http://www.apachesecurity.net&lt;/a&gt;, this &lt;a href="http://www.thinkingstone.com/talks/Web_Intrusion_Detection_with_ModSecurity.pdf" rel="nofollow"&gt;PDF on APIDS&lt;/a&gt; with ModSecurity by Ivan Ristic.  Ryan Barnett also wrote a great book that covered mod_security well, &lt;a href="http://www.awprofessional.com/bookstore/product.asp?isbn=0321321286&#38;rl=1" rel="nofollow"&gt;Preventing Web Attacks with Apache&lt;/a&gt;, which included some custom mod_security rules as well as linked to the now popular &lt;a href="http://gotroot.com" rel="nofollow"&gt;gotroot rulset&lt;/a&gt;.</description>
		<content:encoded><![CDATA[<p>@fak3r: read the last link i provided to &#8220;web security gateway&#8221; or just go to the mod_security website.</p>
<p>there&#8217;s also tons of other resources such as <a href="http://www.apachesecurity.net" rel="nofollow">http://www.apachesecurity.net</a>, this <a href="http://www.thinkingstone.com/talks/Web_Intrusion_Detection_with_ModSecurity.pdf" rel="nofollow">PDF on APIDS</a> with ModSecurity by Ivan Ristic.  Ryan Barnett also wrote a great book that covered mod_security well, <a href="http://www.awprofessional.com/bookstore/product.asp?isbn=0321321286&amp;rl=1" rel="nofollow">Preventing Web Attacks with Apache</a>, which included some custom mod_security rules as well as linked to the now popular <a href="http://gotroot.com" rel="nofollow">gotroot rulset</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: fazed</title>
		<link>http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-71566</link>
		<dc:creator>fazed</dc:creator>
		<pubDate>Tue, 30 Oct 2007 17:23:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-71566</guid>
		<description>@Ofer Shezaf
mod_security is actually very poor
at security a system, although alot
of sys admins rely on it there are many
bypass's to get around its restrictions.
for example an attacker could base64 encode
their GET vars and pass them to a script he
has placed on the server which decodes it
and mod_security does not detect it.
it does mean that the attacker must
first have that file on the webserver
some how but after this the rest is
easy to bypass (such as base path restrictions)</description>
		<content:encoded><![CDATA[<p>@Ofer Shezaf<br />
mod_security is actually very poor<br />
at security a system, although alot<br />
of sys admins rely on it there are many<br />
bypass&#8217;s to get around its restrictions.<br />
for example an attacker could base64 encode<br />
their GET vars and pass them to a script he<br />
has placed on the server which decodes it<br />
and mod_security does not detect it.<br />
it does mean that the attacker must<br />
first have that file on the webserver<br />
some how but after this the rest is<br />
easy to bypass (such as base path restrictions)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: fak3r</title>
		<link>http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-70937</link>
		<dc:creator>fak3r</dc:creator>
		<pubDate>Mon, 29 Oct 2007 21:08:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-70937</guid>
		<description>@Dre
Thanks for the advice, I've moved to Lighty from Apache 2.x on Debian recently, and I run Varnish for a reverse proxy/http accelerator.  Can you tell me how you'd run mod_security in this setup?  Would Varnish intercept php requests and run them through mod_sec or would Lighty use it directly?  If it's easier and you want to help more my email is my username at my username dot com

Thanks!

fak3r.</description>
		<content:encoded><![CDATA[<p>@Dre<br />
Thanks for the advice, I&#8217;ve moved to Lighty from Apache 2.x on Debian recently, and I run Varnish for a reverse proxy/http accelerator.  Can you tell me how you&#8217;d run mod_security in this setup?  Would Varnish intercept php requests and run them through mod_sec or would Lighty use it directly?  If it&#8217;s easier and you want to help more my email is my username at my username dot com</p>
<p>Thanks!</p>
<p>fak3r.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dre</title>
		<link>http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-69630</link>
		<dc:creator>dre</dc:creator>
		<pubDate>Fri, 26 Oct 2007 21:25:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-69630</guid>
		<description>@fak3r: there are multiple ways of running mod_security - the only way it wouldn't work with lighttpd is the apache loaded module that only works with a local installation of apache.

probably the most common way deployed in your scenario (without apache) is in reverse-proxy mode</description>
		<content:encoded><![CDATA[<p>@fak3r: there are multiple ways of running mod_security - the only way it wouldn&#8217;t work with lighttpd is the apache loaded module that only works with a local installation of apache.</p>
<p>probably the most common way deployed in your scenario (without apache) is in reverse-proxy mode</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: fak3r</title>
		<link>http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-69427</link>
		<dc:creator>fak3r</dc:creator>
		<pubDate>Fri, 26 Oct 2007 01:12:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-69427</guid>
		<description>@Ofer Shezaf
As to your performance issues: what rules are you using for ModSecurity? the popular gotroot rules are way to big an inefficient, but on the other hand offer you alot the GRASP does not do provide you, such as blacklists. 

You must have been watching over my shoulder, this is exactly the problem.  I will try again with the core rules only next.

So, is there any way to get mod_security to work with Lighttpd?

Thanks Ofer!</description>
		<content:encoded><![CDATA[<p>@Ofer Shezaf<br />
As to your performance issues: what rules are you using for ModSecurity? the popular gotroot rules are way to big an inefficient, but on the other hand offer you alot the GRASP does not do provide you, such as blacklists. </p>
<p>You must have been watching over my shoulder, this is exactly the problem.  I will try again with the core rules only next.</p>
<p>So, is there any way to get mod_security to work with Lighttpd?</p>
<p>Thanks Ofer!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sandeep Nain</title>
		<link>http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-69394</link>
		<dc:creator>Sandeep Nain</dc:creator>
		<pubDate>Fri, 26 Oct 2007 00:24:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.darknet.org.uk/2007/10/core-grasp-php-web-application-protection-software/#comment-69394</guid>
		<description>I must say that modSecurity is the best WAF i have come across so far and that is because of the flexibility and powerful realtime traffic monitoring and analysis it provides.

it will also give excellent results on big commercial web applications if implemented correctly and not just everyday websites.</description>
		<content:encoded><![CDATA[<p>I must say that modSecurity is the best WAF i have come across so far and that is because of the flexibility and powerful realtime traffic monitoring and analysis it provides.</p>
<p>it will also give excellent results on big commercial web applications if implemented correctly and not just everyday websites.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
