Mailing List Archive

That Apache rule is pretty much useless, it gives a false sense of security. It only blocks those exact strings. Someone could easily put a comment inside a keyword (ie. use "SEL/**/ECT" instead of "SELECT") and this would still be valid SQL, and wouldn't get blocked by that rule.

The best approach here is to do it at an application level. That is, make sure your application is not vulnerable to SQL injection. In the case of a PHP application, you should really be using prepared statements with PDO (or, at least, the MySQLi extension). These have been around for years, the old mysql extension (ie. mysql_query and its friends) have been deprecated for about 8 years now. Check out http://webdevrefinery.com/forums/topic/1272-your-mysql-code-sucks/. SQL injection is by far one of the easiest security problems to avoid, and newer applications should (by nature) not be vulnerable at all.

To properly block this at a server level, you'd need something like mod_security that can use smarter techniques to recognise attack patterns. Unfortunately I don't think there's a Cherokee equivalent of this yet.

Regards,
 - Daniel


----- Original Message -----
From: pub crawler <pubcrawler.com@gmail.com>
To: cherokee List <cherokee@lists.octality.com>
Cc:
Sent: Monday, 10 October 2011 7:56 PM
Subject: [Cherokee] Protecting Cherokee fronted sites from RefRef

Looking for some collective thoughts here on how to shield sites
fronted with Cherokee from Anonymous' RefRef tool.

The anatomy of the tool oversimplified is that it posts to a URL on a
website and sends along in the POST some javascript which pumps this
data to MySQL:

select benchmark(99999999999,0x70726f62616e646f70726f62616e646f70726f62616e646f);

What that does is runs the benchmark to convert the string 99999999999 times.

One solution I've found elsewhere and is Apache specific is this:
.htaccess

RewriteEngine on
RewriteCond %{QUERY_STRING}
.*(/\*|union|select|insert|cast|set|declare|drop|update|md5|benchmark)
[NC]
RewriteRule .* - [R=406,L]

Anyone know of or recommend how to convert this to Cherokee rules?
_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee

_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee

> The anatomy of the tool oversimplified is that it posts to a URL on a
> website and sends along in the POST some javascript which pumps this
> data to MySQL:
>

If a tool sends POST data to an URL, the receiving script should
validate all POST data before doing anything with it.
Using a .htaccess rule is not a clean way to solve this, and I doubt
it is secure.
_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee

As Daniel said... that apache rule is useless and quite nonsense. Just
make your application SQL Injection safe.


Greetings,
Jędrzej Nowak



On Mon, Oct 10, 2011 at 11:38 AM, Daniel Lo Nigro <dan15@ymail.com> wrote:
> That Apache rule is pretty much useless, it gives a false sense of security. It only blocks those exact strings. Someone could easily put a comment inside a keyword (ie. use "SEL/**/ECT" instead of "SELECT") and this would still be valid SQL, and wouldn't get blocked by that rule.
>
> The best approach here is to do it at an application level. That is, make sure your application is not vulnerable to SQL injection. In the case of a PHP application, you should really be using prepared statements with PDO (or, at least, the MySQLi extension). These have been around for years, the old mysql extension (ie. mysql_query and its friends) have been deprecated for about 8 years now. Check out http://webdevrefinery.com/forums/topic/1272-your-mysql-code-sucks/. SQL injection is by far one of the easiest security problems to avoid, and newer applications should (by nature) not be vulnerable at all.
>
> To properly block this at a server level, you'd need something like mod_security that can use smarter techniques to recognise attack patterns. Unfortunately I don't think there's a Cherokee equivalent of this yet.
>
> Regards,
>  - Daniel
>
>
> ----- Original Message -----
> From: pub crawler <pubcrawler.com@gmail.com>
> To: cherokee List <cherokee@lists.octality.com>
> Cc:
> Sent: Monday, 10 October 2011 7:56 PM
> Subject: [Cherokee] Protecting Cherokee fronted sites from RefRef
>
> Looking for some collective thoughts here on how to shield sites
> fronted with Cherokee from Anonymous' RefRef tool.
>
> The anatomy of the tool oversimplified is that it posts to a URL on a
> website and sends along in the POST some javascript which pumps this
> data to MySQL:
>
> select benchmark(99999999999,0x70726f62616e646f70726f62616e646f70726f62616e646f);
>
> What that does is runs the benchmark to convert the string 99999999999 times.
>
> One solution I've found elsewhere and is Apache specific is this:
> .htaccess
>
> RewriteEngine on
> RewriteCond %{QUERY_STRING}
> .*(/\*|union|select|insert|cast|set|declare|drop|update|md5|benchmark)
> [NC]
> RewriteRule .* - [R=406,L]
>
> Anyone know of or recommend how to convert this to Cherokee rules?
> _______________________________________________
> Cherokee mailing list
> Cherokee@lists.octality.com
> http://lists.octality.com/listinfo/cherokee
>
> _______________________________________________
> Cherokee mailing list
> Cherokee@lists.octality.com
> http://lists.octality.com/listinfo/cherokee
>
_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee

I agree that ground up application hardening is the way to go, it's a
mighty hard thing to insure.

Any environment that has multiple developers or multiple users is
going to break that security quickly.

Common open source software is susceptible to this stuff - well a good bit is.

It's easier/better, I believe to have this protection layer up top for
as-needed or just in case protection.

Thanks @Daniel Lo Nigro for the good reading :)
Hopefully, other folks see the wisdom in the top down approach as well :)

Recently, there have been a number of very high profile mass hosting
take overs. There was one company with 40k sites that was entirely
hacked and there was the MySQL.com site hacked by a similar exploit.

I am seeing tons of these and other similar attacks. Seeing tons of
compromised sites in search too :(

On 10/10/11, MoroSwitie <moroswitie@gmail.com> wrote:
>> The anatomy of the tool oversimplified is that it posts to a URL on a
>> website and sends along in the POST some javascript which pumps this
>> data to MySQL:
>>
>
> If a tool sends POST data to an URL, the receiving script should
> validate all POST data before doing anything with it.
> Using a .htaccess rule is not a clean way to solve this, and I doubt
> it is secure.
> _______________________________________________
> Cherokee mailing list
> Cherokee@lists.octality.com
> http://lists.octality.com/listinfo/cherokee
>
_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee