Re: JWT payloads break b64dec convertor
Le 28/05/2018 à 10:19, Adis Nezirovic a écrit : > On 05/26/2018 04:27 PM, Jonathan Matthews wrote: >> Hello folks, >> >> The payload (and other parts) of a JSON Web Token (JWT, a popular and >> growing auth standard: https://tools.ietf.org/html/rfc7519) is base64 >> encoded. >> >> Unfortunately, the payload encoding (specified in >> https://tools.ietf.org/html/rfc7515) is defined as the "URL safe" >> variant. This variant allows for the lossless omission of base64 >> padding ("=" or "=="), which the haproxy b64dec convertor doesn't >> appear to be able cope with. The result of > Jonathan, > > It's not just padding, urlsafe base64 replaces '+' with '-', and '/' > with '_'. For now, I guess the easiest way would be to write a simple > converter in Lua, which just returns the original string, and send > payload somewhere for further processing. For those who like "standards", these are all base64 variants : https://en.wikipedia.org/wiki/Base64#Variants_summary_table Oh, and don't forget to develop a new standard if those don't cover yours needs: https://xkcd.com/927/ > Best regards, > Adis Bunch --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus
Re: JWT payloads break b64dec convertor
On 28/05/2018 17:42, Norman Branitsky wrote: https://en.wikipedia.org/wiki/The_C_Programming_Language Oh, of course *clap on head* how embarrassing 8-O. I haven't thought to THIS Book, sorry. Best regards Aleks -Original Message- From: Aleksandar Lazic Sent: Monday, May 28, 2018 12:34 PM To: Jonathan Matthews Cc: Willy Tarreau ; haproxy Subject: Re: JWT payloads break b64dec convertor On 28/05/2018 15:10, Jonathan Matthews wrote: On Mon, 28 May 2018 at 14:26, Willy Tarreau wrote: On Mon, May 28, 2018 at 01:43:41PM +0100, Jonathan Matthews wrote: > Improvements and suggestions welcome; flames and horror -> > /dev/null ;-) Would anyone be interested in adding two new converters for this, working exactly like base64/b64dec but with the URL-compatible base64 encoding instead ? We could call them : u64dec u64enc I like that idea, and have already retrieved my K&R from the loft :-) Sorry for my ignorance but what's K&R ? J -- Jonathan Matthews London, UK http://www.jpluscplusm.com/contact.html
RE: JWT payloads break b64dec convertor
https://en.wikipedia.org/wiki/The_C_Programming_Language -Original Message- From: Aleksandar Lazic Sent: Monday, May 28, 2018 12:34 PM To: Jonathan Matthews Cc: Willy Tarreau ; haproxy Subject: Re: JWT payloads break b64dec convertor On 28/05/2018 15:10, Jonathan Matthews wrote: >On Mon, 28 May 2018 at 14:26, Willy Tarreau wrote: > >> On Mon, May 28, 2018 at 01:43:41PM +0100, Jonathan Matthews wrote: >> > Improvements and suggestions welcome; flames and horror -> >> > /dev/null ;-) >> >> Would anyone be interested in adding two new converters for this, >> working exactly like base64/b64dec but with the URL-compatible >> base64 encoding instead ? We could call them : >> >> u64dec >> u64enc > > >I like that idea, and have already retrieved my K&R from the loft :-) Sorry for my ignorance but what's K&R ? >J > >> -- >Jonathan Matthews >London, UK >http://www.jpluscplusm.com/contact.html
Re: JWT payloads break b64dec convertor
On 28/05/2018 15:10, Jonathan Matthews wrote: On Mon, 28 May 2018 at 14:26, Willy Tarreau wrote: On Mon, May 28, 2018 at 01:43:41PM +0100, Jonathan Matthews wrote: > Improvements and suggestions welcome; flames and horror -> /dev/null ;-) Would anyone be interested in adding two new converters for this, working exactly like base64/b64dec but with the URL-compatible base64 encoding instead ? We could call them : u64dec u64enc I like that idea, and have already retrieved my K&R from the loft :-) Sorry for my ignorance but what's K&R ? J -- Jonathan Matthews London, UK http://www.jpluscplusm.com/contact.html
Re: JWT payloads break b64dec convertor
On Mon, May 28, 2018 at 03:10:01PM +0100, Jonathan Matthews wrote: > On Mon, 28 May 2018 at 14:26, Willy Tarreau wrote: > > > On Mon, May 28, 2018 at 01:43:41PM +0100, Jonathan Matthews wrote: > > > Improvements and suggestions welcome; flames and horror -> /dev/null ;-) > > > > Would anyone be interested in adding two new converters for this, > > working exactly like base64/b64dec but with the URL-compatible > > base64 encoding instead ? We could call them : > > > > u64dec > > u64enc > > > I like that idea, and have already retrieved my K&R from the loft :-) By the way, another approach (cleaner?) could be to add an argument to the existing b64dec()/base64() to indicate how it should work. I think it's the utf8 or json or something like this which already does exactly this. Willy
Re: JWT payloads break b64dec convertor
On Mon, 28 May 2018 at 14:26, Willy Tarreau wrote: > On Mon, May 28, 2018 at 01:43:41PM +0100, Jonathan Matthews wrote: > > Improvements and suggestions welcome; flames and horror -> /dev/null ;-) > > Would anyone be interested in adding two new converters for this, > working exactly like base64/b64dec but with the URL-compatible > base64 encoding instead ? We could call them : > > u64dec > u64enc I like that idea, and have already retrieved my K&R from the loft :-) J > -- Jonathan Matthews London, UK http://www.jpluscplusm.com/contact.html
Re: JWT payloads break b64dec convertor
On Mon, May 28, 2018 at 01:43:41PM +0100, Jonathan Matthews wrote: > Improvements and suggestions welcome; flames and horror -> /dev/null ;-) Would anyone be interested in adding two new converters for this, working exactly like base64/b64dec but with the URL-compatible base64 encoding instead ? We could call them : u64dec u64enc Note that it can be a nice and useful exercise for a first-time contribution, don't be ashamed guys! Willy
Re: JWT payloads break b64dec convertor
On 28 May 2018 at 12:32, Jonathan Matthews wrote: > I think with your points and ccripy's sneaky (kudos!) padding > insertion, I can do something which suffices for my current audit > needs. For the list, here's my working v1 that I ended up with. I'm sure various things can be improved! :-) I couldn't get ccripy's concat() and length() converters to work, but I've stolen the basic idea - many thanks! acl ACL_jwt_payload_4x_chars_long var(txn.jwtpayload) -m reg ^(.{4})+$ http-request set-var(txn.jwtpayload) req.hdr(jwt) http-request set-var(txn.jwtpayload) var(txn.jwtpayload),regsub($,=) if !ACL_jwt_payload_4x_chars_long http-request set-var(txn.jwtpayload) var(txn.jwtpayload),regsub($,=) if !ACL_jwt_payload_4x_chars_long http-request set-var(txn.jwtpayload) var(txn.jwtpayload),regsub(-,+,g) http-request set-var(txn.jwtpayload) var(txn.jwtpayload),regsub(_,/,g) log-format " jwt-payload:%[var(txn.jwtpayload),b64dec]" Improvements and suggestions welcome; flames and horror -> /dev/null ;-) Jonathan
Re: JWT payloads break b64dec convertor
On 28 May 2018 at 09:19, Adis Nezirovic wrote: > On 05/26/2018 04:27 PM, Jonathan Matthews wrote: >> Hello folks, >> >> The payload (and other parts) of a JSON Web Token (JWT, a popular and >> growing auth standard: https://tools.ietf.org/html/rfc7519) is base64 >> encoded. >> >> Unfortunately, the payload encoding (specified in >> https://tools.ietf.org/html/rfc7515) is defined as the "URL safe" >> variant. This variant allows for the lossless omission of base64 >> padding ("=" or "=="), which the haproxy b64dec convertor doesn't >> appear to be able cope with. The result of > > Jonathan, > > It's not just padding, urlsafe base64 replaces '+' with '-', and '/' > with '_'. You're right. I'd noticed those extra substitutions but, for some reason I'd assumed they were applied after decoding. Brain fart! > For now, I guess the easiest way would be to write a simple > converter in Lua, which just returns the original string, and send > payload somewhere for further processing. One nice thing about the JWT format is that it's unambiguously formatted as "header.payload.signature", so the payload can be trivially parsed out of a sacrificial header with a http-request replace-header copy-of-jwt [^.]+\.([^.]+)\..+ \1 ... or some such manipulation. Here, for clarity, I'm double-passing it through an abns@ frontend-backend-listen chain, hence the additional header and not a variable, as per your example. I think with your points and ccripy's sneaky (kudos!) padding insertion, I can do something which suffices for my current audit needs. I suspect you're right that a Lua convertor is probably the more supportable way forwards, however. Many thanks, both! J
Re: JWT payloads break b64dec convertor
On 05/26/2018 04:27 PM, Jonathan Matthews wrote: > Hello folks, > > The payload (and other parts) of a JSON Web Token (JWT, a popular and > growing auth standard: https://tools.ietf.org/html/rfc7519) is base64 > encoded. > > Unfortunately, the payload encoding (specified in > https://tools.ietf.org/html/rfc7515) is defined as the "URL safe" > variant. This variant allows for the lossless omission of base64 > padding ("=" or "=="), which the haproxy b64dec convertor doesn't > appear to be able cope with. The result of Jonathan, It's not just padding, urlsafe base64 replaces '+' with '-', and '/' with '_'. For now, I guess the easiest way would be to write a simple converter in Lua, which just returns the original string, and send payload somewhere for further processing. Best regards, Adis
Re: JWT payloads break b64dec convertor
while probably not the most ideal solution... i found a quick method to do this using the builtin converters within the configuration to append the padding where necessary. here is an example: log-format %[var(txn.jwtpayload),b64dec] http-request set-var(txn.jwtpayload) req.hdr('x-jwtpayload') http-request set-var(txn.jwtpayload) str(),concat(,txn.jwtpayload,==) if !{ var(txn.jwtpayload),length,mod(4) -m int eq 0 } { var(txn.jwtpayload),length,mod(2) -m int eq 0 } http-request set-var(txn.jwtpayload) str(),concat(,txn.jwtpayload,=) if !{ var(txn.jwtpayload),length,mod(4) -m int eq 0 }