CGI-class changes + to space for BASE64-data

[Pickwick]

Hello all,

I have a web application with it's own little template system, which gets all parameters of a request using the CGI class to build a hash with names and values, which is later in the system used in simple text replacements to put the values under the parameter's names in html templates. The functions used don't know any context, the system is used in three web applications and therefore has to be pretty general to not break anything.

My problem now is that in one context I need to transfer BASE64 encoded data into a template to afterwards can send it back to another target on user's request. The encoded data can contain the +-character, which seems to be converted to a space directly in the CGI-class using CGI::Util::unescape and of course invalidates my data. This behaviour seems to be hard coded and not data dependent or something like that. My only idea to get around this would be to configure a list of parameter names in the template system where spaces can safely be reconverted to +-characters. This sounds error prone to me, because every new parameter has to be configured as well, something which will surely be forgotten over time.

Do you think of any other way to get around this problem?

Thanks!

[moritz]

The + should only be substituted for a space in URL parameters.

Since Base64 data is often rather long anyway, a possible solution is to not use URL parameters for them, but instead POST parameters.

The functions used don't know any context, the system is used in three web applications and therefore has to be pretty general to not break anything.

You can still customize it for just one app, either by inheritance (for OO code), or by wrapping (for procedural code). AUTOLOAD can help you with automtic wrapping.

[Pickwick]

Since Base64 data is often rather long anyway, a possible solution is to not use URL parameters for them, but instead POST parameters.

I get the data via a http redirect and the BASE64 data is just a signature for the other parameter values, therefore it's not that large at all.

You can still customize it for just one app, either by inheritance (for OO code), or by wrapping (for procedural code). AUTOLOAD can help you with automtic wrapping.

I think I will subclass CGI directly and store the needed logic in my own class, because the problem doesn't only occur in the templates, but also if one wants to read the parameter value directly in a program. It's just parse_params which needs to get changed.

[JavaFan]

My only idea to get around this would be to configure a list of parameter names in the template system where spaces can safely be reconverted to +-characters.

Well, you're free to encode your data anyway you want (as long as the resulting URL is valid), but if you're not using "CGI encoding", you shouldn't have CGI::Util::unescape decode it. You should do one of these:
1. 1. Encode your data in BASE64.
   2. CGI-encode the BASE64 data.
   3. Send the data over the wire.
   4. CGI-decode the data.
   5. BASE64 decode the data.
2. 1. Encode your data in BASE64.
   2. Send the data over the wire.
   3. BASE64 decode the data.
3. 1. CGI-encode the BASE64 data.
   2. Send the data over the wire.
   3. CGI-decode the data.
4. Something else.
But you shouldn't not-CGI-encode the data on one end, and CGI-decode it on the other.

[fullermd]

Do you think of any other way to get around this problem?

Yes, URL-encode the data if it's going to somewhat that expects it to be URL-encoded. CGI::Util has an 'escape' function that should DTRT.

[Pickwick]

Yes, URL-encode the data if it's going to somewhat that expects it to be URL-encoded. CGI::Util has an 'escape' function that should DTRT.

The data is already sent using encodeRedirectURL from a Java servlet and + is a proper character.

[ikegami]

You have a URL injection bug. You took a arbitrary text (a base64 string) and used it as a url parameter value without first converting it into a url parameter value. This is the same class of problem which are exploited by SQL injection attacks.

• If you insert text into SQL, you need to turn it into a SQL literal first.
• If you insert text into HTML, you need to turn it into HTML text first.
• If you insert text into a shell command, you need to turn it into a shell literal first.
• And if you insert text into a URL, you need to turn it into an URL component first.

Whenever one interpolates a string into another or concatenate a string with another, one needs to consider whether any conversion is required. Concatenating strings could very well be the biggest security risk of the times. People forget they're not just concatenating strings; they're concatenating the content of those strings.

[chrestomanci]

Have you considered using a different encoding? Base32 springs to mind as is only uses upper case letters and numerals, so nothing will need to be escaped.

[ikegami]

There is an existing module: Convert::Base32