Following this tutorial I'm stuck with figuring out what the part of the signature is supposed to keep.
What is the final struct from the JWT to request access token?
What I'm using is this string:
Base64UrlEncoded(header).Base64UrlEncoded(body).RSASHA256(Base64UrlEncoded(header).Base64UrlEncoded(body), provided_private_rsa_key)
Is this the supposed way of doing it? What I've noticed is that the tutorial in the signature part shows an example completely different from what they describe.
Thank you in advance!
Per JWT.IO, it looks like the format of the signature should be RSASHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret). If the periods in your code don't correspond to literal .s, then those would need to be added.
I'd recommend taking the assertion you're generating and plugging it in to JWT.IO's Debugger along with your public key to confirm you've generated a valid assertion.
Related
In the moment I'm struggling a little bit with the generation of HMAC for Amazon MWS.
I thought I understood how it works.
With the Scratchpad I generated a request. Scratchpad shows the string to sign and also the SHA 256 HMAC and the Base64 HMAC.
The string to sign consists of 4 lines like it's described in the docu.
There are several Onlineconverter for HMAC. I tried:
https://www.freeformatter.com/hmac-generator.html
https://codebeautify.org/hmac-generator
When I convert the string to sign which Scratchpad generated (the 4 lines), I get an other SHA 256 HMAC then Scratchpad generated.
Also there are several Onlineconverter for Base64. I tried:
https://www.freeformatter.com/base64-encoder.html
https://www.base64encode.org
When I convert the SHA 256 HMAC which Scratchpad generated, I get an other Base64-String then Scrathpad generated.
This confuses me. What I don't understand?
Other point:
Later I think I want to use GET and not POST. Do I get this right, that the string to sign for GET also has to be in 4 lines and not in one line as it would be executed later? That's how I understand the docu.
I used these links:
http://docs.developer.amazonservices.com/en_US/dev_guide/DG_QueryString.html
http://docs.developer.amazonservices.com/en_US/dev_guide/DG_SigningQueryRequest.html
https://mws.amazonservices.com/scratchpad/index.html
To answer my own questions.
Generate SHA256 with an Onlineconverter:
I suppose the Problem is the LF. The Onlineconverter maybe have problem with it. Maybe they use CRLF. Better don't try to check your SHA256 with Onlineconverters.
Generate base64 with an Onlineconverter:
The SHA256 Scratchpad shows is not the value you convert with base64. You have to convert the Hex-Value of the SHA256.
Query to sign with GET:
If you want to use GET, the query to sign has to look like the query to sign for POST. Also the four lines. Only swap POST with GET.
My application is using JWT and should prevent replay attacks. I was testing this an ran into the following.
When I have a valid JWT and change the last character of the token/signature the JWT is still valid. E.g. the following token do all validate correctly:
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJTb21lIFRlc3QiLCJjbGFpbSI6IlNvbWUgQ2xhaW0ifQ.UkFYSK7hSSeiqUOSMdbXgbOErMFnuK0Emk1722ny-r4
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJTb21lIFRlc3QiLCJjbGFpbSI6IlNvbWUgQ2xhaW0ifQ.UkFYSK7hSSeiqUOSMdbXgbOErMFnuK0Emk1722ny-r5
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJTb21lIFRlc3QiLCJjbGFpbSI6IlNvbWUgQ2xhaW0ifQ.UkFYSK7hSSeiqUOSMdbXgbOErMFnuK0Emk1722ny-r6
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJTb21lIFRlc3QiLCJjbGFpbSI6IlNvbWUgQ2xhaW0ifQ.UkFYSK7hSSeiqUOSMdbXgbOErMFnuK0Emk1722ny-r7
I have checked this on http://jwt.io/ and can be reproduced in my .Net application as well.
Can someone explain how it is possible that the signature is not unique for a given payload? I understand that collisions can occur, but I cannot explain that they are consecutive sequences.
In this special case you are changing the base64 url encoding of the signature, not the signature itself
The fourth base64 values encode the same binary value. Try converting to hexadecimal at http://kjur.github.io/jsjws/tool_b64udec.html
The value you will see is
52415848aee14927a2a9439231d6d781b384acc167b8ad049a4d7bdb69f2fabe
If you change the suffix to -r1 or -r8 then the binary value changes and signature validation will fail
Can two different BASE 64 encoded strings result into same string if decoded?
When you change the signature (the last part) you can still decode the JWT to see the header and payload. However, if you attempt to validate the JWT with the changed signature, that validation will fail.
I am trying to do an XSL transform on an xml structure in a bpel assignment statement. There is a syntax problem, but I am having trouble finding official documentation. There are examples all over the internet but I have not found a clear explanation. Here is my best shot. What do the last two parameters do? Why is eclipse saying the first argument must be a literal, even though test3.xsl is a string?
<bpel:assign validate="yes" name="Assign">
<bpel:copy keepSrcElementName="no">
<bpel:from>
<![CDATA[bpel:doXslTransform("test3.xsl", $personalInfoServiceOutput.parameters), "middle", $positionSkillManagementInput]]>
</bpel:from>
<bpel:to variable="positionSkillManagementInput"></bpel:to>
</bpel:copy>
</bpel:assign>
The signature of doXSLTransform looks as follows:
object bpel:doXslTransform(string, node-set, (string, object)*)
The first parameter is the name of the XSLT script, the second parameter is an XPath identifying the source document (e.g. a variable, part, nodeset, node). The third and the fourth parameter is a key-value pair, the string is the key and the object is the value. Those pairs are mapped into the script's parameter context so that you can access these values by their name in the script. There can be any number of these pairs.
The best resource to look up such things is the WS-BPEL 2.0 specification, doXSLTransform is described in Sect. 8.4
When I use the following code :
<bpel:copy keepSrcElementName="no">
<bpel:from>
<![CDATA[bpel:doXslTransform("parseSample.xsl", $output.payload)]]>
</bpel:from>
<bpel:to variable="output"></bpel:to>
</bpel:copy>
I also get the error, that first argument must be literal string.
But, when I deploy my service (with error) to wso2 bps, it works fine.
You can try with this.
I faced the same issue. Agree with NGoyal. Shows error in BPEL but works when deployed.
I am a bit confused by what I see and hence headed over to SO.
I am developing a BizTalk (2010) Orchestration and I am wanting to parse an incoming XML message. I just need to retrieve then number of times a particular node is repeating. I could have used XPath. But, I chose to use LinqToXml.
I have created a variable of type System.Xml.Linq.XNamespace and inside an expression shape, I am assignning it a string value.. say http://mycompany/v1.0. This is a perfectly valid C# statment, as there is an implicit conversion from String to XNamespace (MSDN link).
But the Orchestration will not compile at all. I get this error cannot implicitly convert type System.String to System.Xml.Linq.XNamespace.
And if I dont use the XNamespace variable and directly run LinqToXml on the incoming message like this
MessageCount = MyXElement.Elements("{http://mycompany/v1.0}ListOfNotifications").Elements("{http://mycompany/v1.0}Notification").Count();
I get a cannot convert from String to XName error. Even this is confusing.
I am using BizTalk 2010 and C# 4.0. Can someone explain if I am missing something? I have tried all these code snippets using LinqPad and I get the expected response. So, there are no typos or missing references.
I opted to use the XPath option to retrieve the values that I needed, instead of using LinqToXml. The code that I ended up writing looks like below:
xpath(myOrchVariable, "string(/*[local-name()='InputRootNode' and namespace-uri()='http://my/name/space'])")
I'm using a validation library that removes some common XSS attacks from the input to my web application. It works fine, and I'm also escaping everything I render to protect against XSS attacks.
The library contains this line in part of the XSS filtering process:
// Protect query string variables in URLs => 901119URL5918AMP18930PROTECT8198
str = str.replace(/\&([a-z\_0-9]+)\=([a-z\_0-9]+)/i, xss_hash() + '$1=$2');
xss_hash returns a string of random alpha-numeric characters. Basically it takes a URL with a query string, and mangles it a bit:
> xss('http://example.com?something=123&somethingElse=456&foo=bar')
'http://example.com?something=123eujdfnjsdhsomethingElse=456&foo=bar'
Besides having a bug (it only "protects" one parameter, not all of them), it seems to me the whole thing is itself a bug.
So my question is: what kind of attack vector is this kind of replacement protecting against?
If it's not really doing anything, I would like to submit a patch to the project removing it completely. And if it is legitimately protecting users of the library, I'd like to submit a patch to fix the existing bug.
xss_hash returns a string of random alpha-numeric characters.
Are they definitely random, or is it generated based on computable data?
It appears to be Security through obscurity: it's trying to replace all the &'s with xss_hash()'s so that the query is less readable. I'm guessing there is a part of the library which undoes this (i.e. treats all the xss_hash()'s in the string as &s for parsing purposes).
The code in question "protected query string variables" by replacing the & separating URL parameters with a random string, before doing some other processing that would remove or otherwise mangle ampersands. As Jay Shah pointed out, there was code just below that was meant to replace the query string ampersands, but another bug was preventing it from working as intended.