I'm working on a reset password function that matches hashes to allow for the user to reset. The only trouble is the hash that was created cannot be passed over URL without breaking the page. For example, my hash is this:
http://localhost/users/changeResetPassword/e0b4ab1d2cdc5742c7b5f72ef6c2935dadfe458dc275b7419d9f1ac66461aa20%0F5%3A%C6%5C%26%2A%E4%D5%ACA%94%ADV%BF%EB%CAz%97O%1F%7D%F0h~%E3-.%FF%B4z%5E%1AQ%B8%8Ca%BC500%2A%EC%7B%FA%AF8%E3%2A%7F%BA%A4y%03%AE%29%94%09%26%9E%29e%E5%DEn%1At%C1%EC%F7%D4x%EAvlA%BE%5B%0D%CF
All of these % seem to break the page, because I get this error:
Object not found!
The requested URL was not found on this server. If you entered the URL manually please check your spelling and try again.
If I take away everything up to the last % and try it again, the page loads fine. It's just some characters in the URL seem to bug everything out:
http://localhost/users/changeResetPassword/e0b4ab1d2cdc5742c7b5f72ef6c2935dadfe458dc275b7419d9f1ac66461aa20
This loads fine, so I know it's just a URL problem. Any ideas?
Base64 encode the hash and pass it along, then decode when received. Cake URI parsing likely breaks because it'll try to interpret those %xx as html encoded values but it does not appear that is what they are since you have stuff like %03 and from the link: "The ASCII device control characters %00-%1f were originally designed to control hardware devices. Control characters have nothing to do inside a URL"
With regards to ndm's comment indicating you may additionally need to URL encode the base64 string since base64 can contain the characters + = / I'd recommend you also look at url encoded forward slash is breaking url to see why simply encoding the problematic characters might also be problematic. If the current solution of passing unencoded base64 strings is not causing any issues with your rewrite rules I would recommend you keep it as it.
Related
I'm trying to learn how to use Laravel Sanctum authentication. When I send GET https://localhost/sanctum/csrf-cookie I get the following CSRF cookies:
XSRF-TOKEN=eyJpdiI6Inhvb0FDVXdHZDU5QzBqQTNKaWNxTUE9PSIsInZhbHVlIjoiSXNudjNiNE9xbmtNVWdsQ0l2SDRyYUNPQXIrTGJLb2ZMVDc2NWttenZGY0NkcDRvQzFVQlZOMDRlNFdTOHJaNiIsIm1hYyI6ImY0Y2M2YzZiZWIxYWVmZTRmMWI5NWRhNTBhN2JmM2VjNGExYjU0MGYwYWVmYTE4ODQxM2I0YTFlMWVjZTVhMDkifQ%3D%3D;
You can notice the strange %3D%3D at the end of the token. These characters also added for my laravel_session cookie.
When I then send back a request with this exact token in the header X-XSRF-TOKEN, I'm getting token mismatch error. When I remove the characters - all works. I wonder where's these characters came from and how can I remove them.
UPD: since those were encoded URL characters, when I decoded them and put '==' instead at the end of X-XSRF-TOKEN, that seems to be working. Still, it's strange why it worked before when I just removed the characters from the query manually.
Yeah this stands for the = symbol which is part of your base64'ed CSRF token. I'd guess it only works when you remove it because the = symbol is the special padding character. In a very high level they just pad the string out to the proper length.
As you already know, = becomes %3D when it is url encoded.
Usually when you encounter a string with lot of numbers and characters in random order and it ends with == there is a very high probability that it is encoded in base64.
= is added (at the end of the string) as padding to match a specific number of characters in a string. You can read more about it in this answer.
To answer your question, I will try decoding the given token with and without == at the end, I'll use this online decoder, so you can try it at your end aswell.
With ==:
{"iv":"xooACUwGd59C0jA3JicqMA==","value":"Isnv3b4OqnkMUglCIvH4raCOAr+LbKofLT765kmzvFcCdp4oC1UBVN04e4WS8rZ6","mac":"f4cc6c6beb1aefe4f1b95da50a7bf3ec4a1b540f0aefa188413b4a1e1ece5a09"}
Without ==:
{"iv":"xooACUwGd59C0jA3JicqMA==","value":"Isnv3b4OqnkMUglCIvH4raCOAr+LbKofLT765kmzvFcCdp4oC1UBVN04e4WS8rZ6","mac":"f4cc6c6beb1aefe4f1b95da50a7bf3ec4a1b540f0aefa188413b4a1e1ece5a09"}
They are same.
It works because they (=) are just padding and they DO NOT contain any information.
I am no laravel expert but, I am guessing the reason it doesn't work with %3D is because it is not decoding the url.
I'd like to somehow obscure the contents of $url = "http://blah.somedomain.com/contents/somefolder/somefile.htm"; so I can use them for links but so that the URLs are not easily read by humans when looking at the page source. The obfuscated URL still needs to work in a browser when clicking on it though so other methods of obfuscation that I've looked at are no good.
What we're after is e.g. $obscureurl = "%3A%2F%2F"...etc
Any ideas? Thanks.
Edit: Thanks for suggestions so far, but to clarify, I should have said that I'm not after encoding into HTML entities (the # values), I'm after Percent-encoding (hex values in ASCII).
For example, to change hello#me.com into: %68%65%6c%6c%6f%40%6d%65%2e%63%6f%6d
ASCII table is here for the hex of each letter and symbol: http://ascii.cl/
Is this kind of complete conversion possible with PHP? Thanks
$url = '..';
$encoded = join(array_map(function ($byte) { return "%$byte"; }, str_split(bin2hex($url), 2)));
That's essentially the entire encoding mechanism. Take the raw bytes in hex (bin2hex), 2 characters per byte, and prepend a %.
Not that this will really do a whole lot for obfuscation. The browser may indeed not even display it in its encoded form, and even search engines may display only the decoded form. Further, you're still producing a canonical URL. It doesn't matter what exactly that URL contains; if people have a link to it, they have a link to it, regardless of how human readable that link may or may not be.
I can see 2 easy ways to achieve this:
Replace every character of your link by its html entity (see How to convert all characters to their html entity equivalent using PHP)
Use some kind of ids and save the matching url in your DB: (something like http://example.com/redirect/412)
I am trying to call the USPS API that takes in the zip code and returns XML containing the City Name of the given zip code.
Here is the URL they require:
http://production.shippingapis.com/ShippingAPITest.dll?API=CityStateLookup
&XML=<CityStateLookupRequest USERID="xxxxxxx"><ZipCode ID= "0">
<Zip5>90210</Zip5></ZipCode></CityStateLookupRequest>
In my PHP file, when I echo out the above URL, this is what I get:
http://production.shippingapis.com/ShippingAPITest.dll?API=CityStateLookup&XML=90007
All the XML part of the URL is missing. I need to get curl data from the URL.
Anyone know what I could be missing?
Anyone know what I could be missing?
Probably. Maybe, yes. What you describe in your posting sounds like an encoding problem. So you are missing the right encoding.
As you are talking about an URL that is likely URL encoding. Some characters - like space - have a special meaning inside an URL so you can not just use any character as you like, but you need to encode all characters properly.
The exact description how you need to formulate an URL incl. the exact description how URL encoding works is outlined in 2. Characters in the internet standard RFC3986.
PHP functions related to URL encoding are urlencode() and rawurlencode and more likely useful in your case http_build_query().
http://php.net/manual/en/function.urlencode.php should get you started if you want to encode the xml into the URL.
I have a search script where the user input some querywords that are sent with GET. If the user input contains special characters e.g. äpple the url becomes search.php?q=äpple and everything works fine. But if the user reruns this url search.php?q=äpple the browser address field shows search.php?q=%E4ppleand the query fails. How should I decode that string. urldecodedid not work. I thought this was exactly what it was for so is something else wrong? Or which other functions can I try?
UPDATE
if I use utf8_encode on the search.php?q=%E4pple it produces the right ächar but if the string in the url is sent by GET and thus correctly (and working) äalready, the utf8_encode messes it up.
I guess I can make a condition were I check the encoding before doing something but isnt it an easier way??
Solved it by checking the encoding of $_GET['q'] and handle it appropriately for the result of the encode check. See http://php.net/manual/en/function.utf8-encode.php for functions that check encode.
I am using codeigniter php framework. I have a url that looks like this:
www.mydomain.com/controller/function/param
however, when the param value has encoded characters such as 'plus%2b' all that I can see (by checking the parameter) is 'plus'. So basically I am loosing all encoded characters and anything that may occur after them. I tried accessing the uri string directly using $this->uri->segment(n) but got the same issue.
How can I preserve encoded values so that if the url looks like: www.mydomain.com/controller/function/plus%2b, I get the string 'plus+'?
I think in config.php there is a whitelist of allowed characters (permitted_uri_chars), so you probably would need to add the additional characters here.