Re: JWT payloads break b64dec convertor

[Benoît GARNIER]

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

[Aleksandar Lazic]

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 from the loft :-)


Sorry for my ignorance but what's K ?


J


--

Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html

RE: JWT payloads break b64dec convertor

[Norman Branitsky]

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 from the loft :-)

Sorry for my ignorance but what's K ?

>J
>
>> --
>Jonathan Matthews
>London, UK
>http://www.jpluscplusm.com/contact.html

Re: JWT payloads break b64dec convertor

[Aleksandar Lazic]

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 from the loft :-)


Sorry for my ignorance but what's K ?


J


--

Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html

Re: JWT payloads break b64dec convertor

[Willy Tarreau]

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 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

[Jonathan Matthews]

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 from the loft :-)

J

> --
Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html

Re: JWT payloads break b64dec convertor

[Willy Tarreau]

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

[Jonathan Matthews]

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

[Jonathan Matthews]

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

[Adis Nezirovic]

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

[cripy]

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 }