| Re: Encoding Problems [message #186363 is a reply to message #186358] |
Mon, 07 July 2014 01:24   |
Denis McMahon
Messages: 634
Registered: September 2010
Karma:
|
Senior Member |
|
|
On Sun, 06 Jul 2014 07:14:06 -0400, Richard Damon wrote:
> On 7/6/14, 1:21 AM, Gordon Burditt wrote:
>>> multipart/form-date would be a value for Content-Type, not a value for
>>> Content-Transfer-Encoding.
>>> The defined vauls (By RFC 2045) of Content-Transfer-Encoding are:
>>> quoted-printable base64 binary 8bit 7bit
>> Never forget that viruses and malware aren't required to obey the
>> rules, and you could very well end up with Content-Type: spam/virus and
>> Content-Transfer-Encoding: rot13 .
> And if you don't properly "decode" that payload there is a problem?
No, but doing something sensible and clean in the face of unexpected data
values is better than just bombing out.
My original points are and remain that (a) the values you get for the
content-transfer-encoding might not be in your list, and (b) that the
actual content-transfer-encoding might not match the declared content-
transfer-encoding.
This combination of factors means that having a default that assumes "if
it didn't match anything else it must be x" is a bad idea. It also means
that it's a good idea to expect and try and cleanly detect any content
decoding errors, on the assumption that at some point malformed content
will arrive and you want to handle it in a manner that, at the very
least, doesn't create a vulnerability.
--
Denis McMahon, denismfmcmahon(at)gmail(dot)com
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]