Not able to read complete cookie in perl - perl

I am receiving below cookie from my source system
ExternalAccess=unixtime=1593603710&oracletime=01-jul-20
12:41:50_Hash_thNnmggU2ex3L5XXeMNfxf8Wl8STcVZTxscSFEKSxa0
At destination system [PERL based], using below code to read the cookie
my $extSysCookie = $Query->cookie('ExternalAccess');
i am getting below output
External Access cookie = unixtime=1593603710
and not able to read full value.All characters after & are getting omitted. Can anyone help?

First of all, that's not a valid cookie. Spaces are not allowed in the value of cookies. Ref.
Secondly, that's not a correctly formatted cookie for CGI.pm's ->cookie. ->cookie is designed to handle cookies created using CGI.pm's ->cookie. The cookie value in question was not created with that method, and the cookie can't be handled (correctly) by that method.
To get the desired string from ->cookie, either construct the cookie using ->cookie, or otherwise create a cookie with the URI-encoding the value you wish ->cookie to return.
For example, the desired string will be returned for a cookie with the value
unixtime%3D1593603710%26oracletime%3D01-jul-20%2012%3A41%3A50_Hash_thNnmggU2ex3L5XXeMNfxf8Wl8STcVZTxscSFEKSxa0
CGI's approach allows cookies to have multiple values, and gets around the problem of spaces being forbidden in the values of cookies.

Related

Are CSRF tokens base64url encoded?

I'm working on an application that parses a CSRF token from a cookie header. I'd like to know whether CSRF tokens are base64 encoded with URL-safe characters (cf. https://simplycalc.com/base64url-encode.php) so that I can match them with the regular expression
[.a-zA-Z0-9_-]+
I was able to find documentation on JSON web tokens (JWTs) indicating that they consist of base64url-encoded portions separated by periods ('.'), but I wasn't able to find similar documentation on CSRF tokens.
Are CSRF tokens also generally limited to a certain character set, or can they contain any characters?
A CSRF token is an opaque "nonce" that doesn't contain any info -- the token in the form submission and the token in the cookie or header simply have to match is all. If you see them base64-encoded, it's just for convenience of transmission, but it won't decode to anything useful, just random bytes most of the time. Nothing like the JSON structure of JWT.
Looking at my current framework (Laravel), its CSRF tokens are just random strings (they're derived from base64, but not valid base64). Chances are that's the case for most other frameworks too.

Invalid signature returned when previewing 7digital track

I am attempting to preview a track via the 7digital api. I have utilised the reference app to test the endpoint here:-
http://7digital.github.io/oauth-reference-page/
I have specified what I consider to be the correct format query, as in:-
http://previews.7digital.com/clip/8514023?oauth_consumer_key=MY_KEY&country=gb&oauth_nonce=221946762&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1456932878&oauth_version=1.0&oauth_signature=c5GBrJvxPIf2Kci24pq1qD31U%2Bs%3D
and yet, regardless of what parameters I enter I always get an invalid signature as a response. I have also incorporated this into my javascript code using the same oauth signature library as the reference page and yet still get the same invalid signature returned.
Could someone please shed some light on what I may be doing incorrectly?
Thanks.
I was able to sign it using:
url = http://previews.7digital.com/clip/8514023
valid consumer key & consumer secret
field 'country' = 'GB'
Your query strings parameters look a bit out of order. For OAuth the base string, used to sign, is meant to be in alphabetical order, so country would be first in this case. Once generated it doesn't matter the order in the final request, but the above tool applies them back in the same order (so country is first).
Can you make sure there aren't any spaces around your key/secret? It doesn't appear to strip white space.
If you have more specific problems it may be best to get in touch with 7digital directly - https://groups.google.com/forum/#!forum/7digital-api

How is a mojolicious session token created?

Are mojolicious session tokens created in a "standard" way (in a generic sense), or is this up to the individual application? If it is the former, then what is the format?
What I saw so far is a base64 encoded JSON fragment (which by itself is syntactically incomplete), followed by "---", followed by a random looking 40-digit hex-string.
I'm especially interested in the random looking token. Is it randomly generated, or is it the encoding/encryption of something?
Mojolicious session have base64 string (in the begin, first part) and sign (in the end, second part) which separated by "---".
Sign is main part of session which prevent from changes.
So, make a test:
Add to session some value. Make request which get this value in the session.
Get session and transform first part of them (make base64_decode and change value then make base64_encode and put it before "--" in cookies).
Make query to server with new cookie/session. Your new data must be invalid in session.
So, sign it is IMPORTANT part of session.
Read source code to learn more about it
Read this to know how to set secret key for sign cookies

Powershell Net-Cookie Expires

We are using PoSH Server for our Webservices.
Does anyone know how to change / set the cookie expires in our script? This is how we currently try to do it:
$Response = $Context.Response
$Response.Headers.Add("Accept-Encoding","gzip");
$Response.Headers.Add("Server","PoSH Server");
$Response.Headers.Add("X-Powered-By","Microsoft PowerShell");
$Cookie = New-Object Net.Cookie
$Cookie.Name = "SessionID"
$Cookie.Value = New-TimeStamp
$Cookie.Expires = now+10
$Response.AppendCookie($Cookie)
We also tried s.th. like: $Cookie.Expires = DateTime.Now.AddMinutes(10) a.s.o.
The cookie is read in the following way:
$Cookies = $Request.Cookies["PoSHSessionID"];
The Cookie Expires (Lifetime) does not change. It´s always: Lifetime ends of session.
I am able to get it to set send along a value based on the date set to the Expires property, but it sends it as "max-age" instead of "expires" in the http header, which it would seem (from a quick internet search) isn't supported by at least IE of lower versions.
I'm not used to using the System.Net.HttpListenerResponse type (more used to the System.Web namespace used in ASP.NET) so I'm very likely missing something very obvious, but the only way I could get it to work as I wanted was to add the Set-Cookie header manually. An example on how to do this would be the following:
$Context.Response.Headers.Add("Set-Cookie", "myCookieName=myCookieValue; expires=Tue, 12-Jan-2016 01:14:40 GMT")
Do be aware, however, that you might have special characters in your cookie value which makes your Set-Cookie string invalid. A possible way to work around that could be to create the cookie value string using the System.Net.Cookie class, like you are doing, and just add the Set-Cookie header with the ToString() of the cookie with a manually appended expires value (ensure they are separated with a semicolon).
This does feel very much like an ugly work-around which shouldn't at all be necessary. I'm probably missing something, but on my virtual test machine (Win7, PowerShell 2.0, .NET 4.0, IE10, FF26) I couldn't get it to send Expires instead of Max-Age.
You can find a description of the format for the expires date at the Wikipedia page about HTTP cookies under the header 'Expires and Max-Age'.

Is 'auth_token' and 'sig' the same thing in facebook api?

I am reading facebook api and ran into a little confusion, and hope that you might help. I am using the Javascript SDK specifically, and on getting the request.session back from the login callback, I wonder if the field 'sig' is the same as the 'auth_token'? I know the descriptions of both are different, but I wonder if they are the same in reality. If anyone knows, I will be much appreciated. Thanks in advance.
auth_token is a token that Facebook generates for desktop applications that you must send back to Facebook again immediately when logging in.
sig on the other hand is a md5 hash of all session data combined with your application's private key. You can reconstruct the sig from the session data and compare it with the sig passed in, and if it matches the response can be considered authentic.
Consider the following keys stored as a cookie:
a=1
b=2
sig=8a80b0b971da5be75e7197576331b24e
Assume the application's private key is "hello". We can try to reconstruct the sig as:
md5("a=1" + "b=1" + "hello"); // 8a80b0b971da5be75e7197576331b24e
which equals the value of sig in this case. We constructed this by concatenating all key=value pairs in alphabetical order by key ("a" comes before "b"), then concatenate the private key and finally get the md5 of the resulting string.
I wrote a blog post for verifying the cookie set by Facebook in Rails (PHP example is already given on Facebook's website).