I've been having a bit of a look over the code and one issue struck me.
I was wondering if this has been considered:
In CgiEnvironment.cpp, the memory for the posted data is allocated as
follows:
std::vector<char> data(getContentLength());
Would it be possible to make several requests with a false content
length? Say:
Content-Length: 2000000000
I think this would soon lead to denial of service for legitimate users
of the cgi script as memory would be exhausted (and swapping would
probably slow the system down). I'm not sure if I've thought this
through properly, so please correct me if I haven't.
A possible solution might be to accept the data into a file rather that
allocating the entire amount indicated by the content length header.
This would not add significant performance penalty as there won't be any
disk IO if there is enough memory for the file to be buffered and if the
file is deleted soon after it is created. In fact, the ability to swap
the file buffers out of physical memory might improve performance. I'm
not sure, however, if this could be done easily in a platform
independent manner. Perhaps it could be a compile time option?
I've also run into another problem with session validation using
cookies. Unfortunately, during a file upload, this session validation
cannot be performed as the CgiEnvironment object can't be instantiated
before the upload is complete. This is a problem because I'm wanting to
check the cookie before continuing to accept the file upload.
To me it would make more sense to retrieve the data from the client in
the Cgicc object so that the CgiEnvironment object can be used (for
example, to retrieve cookies) before all of the data has been retrieved.
Apart from these issues, I've been very happy with the library. It's one
of the few C++ libraries that actually makes use of the language features.
Regards,
Russell Kliese
P.S. What is the likelihood of a patch being accepted to solve these
issues if it was done properly?
_______________________________________________
help-cgicc mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-cgicc