Base64 Data Missing Padding Does Not Throw Error
Description
Environment
Activity
Brent Putman April 12, 2016 at 3:34 PM
No, as I mentioned above (just above the code snippet, easy to miss), v3 Base64Support doesn't have this problem. Apache commons-codec works without the padding. I tested it.
Rod Widdowson April 12, 2016 at 1:00 PM
Do we need a similar case for net.shibboleth.utilities.java.support.codec.Base64Support ? I'm assuming not. From org.apache.commons.codec.binary.Base64.decode
Brent Putman April 11, 2016 at 8:03 PM
Won't fix, V2 is end-of-life, and this isn't a security vulnerability.
Brent Putman April 11, 2016 at 8:02 PMEdited
Confirmed Paul's diagnosis. This is easy to deal with gracefully by adding a couple of lines of code to the top of the Base64#decode(String) method, as below. So this can be a local solution for people if they can't get the sender to fix their request message encoding.
Fwiw, v3 doesn't have this issue, as its Base64Support is simply a wrapper around Apache commons-codec.
Paul Hethmon April 11, 2016 at 5:19 PMEdited
My suggestion is that either an exception be thrown about improper Base64 or the padding is assumed. Either will lead to quicker and easier debugging.
An inbound AuthnRequest that is missing the proper padding will still decode but yield invalid XML.
Given the Base64 encoded string of:
Will decode successfully but will be missing the ending greater than symbol to properly close the XML. This then leads to an XML exception (which is hard as hell to track down).
For comparison, Apache Commons Codec will decode it and evidently assume padding and produce valid XML.