|
in reply to Re^4: The most powerful CMS developed in Perl (not spam, sounds that way) (without functions)
in thread The most powerful CMS developed in Perl (not spam, sounds that way)
Hi,
Reading the relevant documentation on CGI.pm shows the two so called 'DOS attacks' you refer to are disabled by default and left to the web server, as does my own 'cooked CGI'. This is not a bug or security issue.
There are no other security bugs and the system is fully protected and tested against SQL injection.
Should you have any further advice can you please point out with at least one line of relevant code. If not, I'd appreciate it if you can drop the negativity. I'm here to get it right and will solve any issues that are identified.
Any statements are justified. If you install the system and get it up and running you will see the hugely powerful security and the differentiation that it can do.
I sympathasise that installation is not as straight forward as others and documentation is lacking, but again this is powerful software for web developers not web users.
Yours, Andrew |
Re^6: The most powerful CMS developed in Perl (not spam, sounds that way) (without functions)
by chromatic (Archbishop) on Mar 14, 2013 at 06:13 UTC
|
What web server are you using that magically corrects incorrect Content-Length headers for you without reading the input stream?
You didn't address the data loss or the incorrect parameter separator bugs either, and I just noticed you ignore the encoding of input. Why?
| [reply]
[d/l] |
|
|
Re: input length, ref: http://perldoc.perl.org/CGI.html#Avoiding-Denial-of-Service-Attacks, which states such functionality is not enabled by default, the web-server can limit resources for CGI scripts.
Which data loss 'bug' are you referring to? This code has been running for years now with no data loss?
Parameter separator bug, I presume you are talking about the lack of '=' also setting the value to 1. This is a feature to cut the URI string down.
The URI input is parsed using a standard method and is UTF8 compatible;
$v =~ s/%(0-9A-Fa-f{2})/chr(hex($1))/eg;
| [reply] |
|
|
Re: input length
That says nothing about the Content-Length header. Sure, you could configure your web server to kill the execution of your program after it performs a blocking read for more than 90 seconds, but it wouldn't take much effort at all to DOS your server by sending tiny trivial requests.
Which data loss 'bug' are you referring to?
The one where you lose query parameters.
Parameter separator bug, I presume you are talking about the lack of '=' also setting the value to 1.
Nope. Read the RFCs.
The URI input is parsed using a standard method and is UTF8 compatible
I didn't write "UTF-8". I wrote "encoding". What if, for example, one of your users uses IE on Windows and submits a form with the CP-1252 encoding? Do you know if you handle that correctly? Are you sure that you're decoding characters outside of the ASCII range correctly?
| [reply]
[d/l] |
|
|
|
