Deployment question: Anyone using modSecurity (or equiv) to ensure hackers keep out of Seaside?

> Since Seaside doesn't have any of the things listed at
> http://www.modsecurity.org/documentation/Securing_Web_Services_with_ModSecurity_2.0.pdf,
> namely:
>
>   Variable-length buffer injection
>   Meta character injection
>   SQL injection
>   SOAP fault code disclosure
>
> I'm not sure why you think modsecurity would help.

>>>>>> "Rick" == Rick Flower <[hidden email]> writes:
>
> Rick> So.. In reviewing the issue involved with this it appears that something
> Rick> like ModSecurity (see links below) and rules from GotRoot.com might help
> Rick> prevent this sort of thing from happening and was curious if anyone
> Rick> running Seaside/Apache combinations has gone down this path to ensure
> Rick> naughty things don't get passed into Seaside if possible.. Obviously I
> Rick> realize that PHP != Smalltalk and that exploits could be different but
> Rick> I'd like to reduce the chances as best I can.
>
> Since Seaside doesn't have any of the things listed at
> http://www.modsecurity.org/documentation/Securing_Web_Services_with_ModSecurity_2.0.pdf,
> namely:
>
>  Variable-length buffer injection
>  Meta character injection
>  SQL injection
>  SOAP fault code disclosure
>
> I'm not sure why you think modsecurity would help.
>
> Assuming you're using GLORP for most of your sql, and follow best practices
> for the small stuff that you would handwrite, of course.
>
> The reason most PHP suffers from this stuff is that (a) PHP is written in C
> and (b) many PHP coders are notoriously bad at understanding metacharacters
> and (c) most PHP coders do not appear to understand SQL placeholders.  And
> SOAP is just bad. :)

> 2009/2/16 Randal L. Schwartz <[hidden email]>:
>>>>>>> "Rick" == Rick Flower <[hidden email]> writes:
>>
>> Rick> So.. In reviewing the issue involved with this it appears that something
>> Rick> like ModSecurity (see links below) and rules from GotRoot.com might help
>> Rick> prevent this sort of thing from happening and was curious if anyone
>> Rick> running Seaside/Apache combinations has gone down this path to ensure
>> Rick> naughty things don't get passed into Seaside if possible.. Obviously I
>> Rick> realize that PHP != Smalltalk and that exploits could be different but
>> Rick> I'd like to reduce the chances as best I can.
>>
>> Since Seaside doesn't have any of the things listed at
>> http://www.modsecurity.org/documentation/Securing_Web_Services_with_ModSecurity_2.0.pdf,
>> namely:
>>
>>  Variable-length buffer injection
>>  Meta character injection
>>  SQL injection
>>  SOAP fault code disclosure
>>
>> I'm not sure why you think modsecurity would help.
>>
>> Assuming you're using GLORP for most of your sql, and follow best practices
>> for the small stuff that you would handwrite, of course.
>>
>> The reason most PHP suffers from this stuff is that (a) PHP is written in C
>> and (b) many PHP coders are notoriously bad at understanding metacharacters
>> and (c) most PHP coders do not appear to understand SQL placeholders.  And
>> SOAP is just bad. :)
>
> I have seen an arbitrary remote code excution vulnerability in Squeak
> including SOAP. Except that there was nothing SOAP specific about it.
> It included something as simple as converting a String to a Boolean.
>
> Given the PostgreS Squeak driver doesn't support prepared statements I
> would be very cautios about any database related statements especially
> considering that various vulerabilities in PHP can only be solved by
> passing the character set of the input to the driver or using prepared
> statements. Glashaus und so.