Im wondering if I can detect whether some webpage was reached by a link (button, link, redirect, ...) or by typping in the URL bar.
Im using Clojure for web programming, and I wish I could block the access to some page when the request came from a "typed url".
Right now I am encoding the urls so the user can't have access to the "real" url.
Thanks in advance.
Short answer is no. Your aproach is correct.
And with a bit of skills one can also send arbitrary HTTP requests, GET or POST, modifying cookies, headers and the body of the request, so if this is about security, your approach to use encrypted data seems the only one possible to ensure that the URL is not tampered or manually typed.
The HTTP Referer header can be also faked, the same as a url parameter. There is no more security on using a http header or a url encoded parameter.
Courtesy of Wikipedia:
The HTTP referer (originally a misspelling of referrer[1]) is an HTTP header field that identifies the address of the webpage (i.e. the URI or IRI) that linked to the resource being requested. By checking the referrer, the new webpage can see where the request originated.
I assume you can access the HTTP header fields. If the user were to type in the URL into the address bar, there would be no HTTP referer.
Related
I am new to HTTP requests (GET, POST, PUT, ETC.) and I am having some issues understanding the "anatomy" of these procedures.
What exactly is the difference between the body and the data? Are they the same thing? Or are headers the same thing as the param? When authentication takes place, are the username and password params or headers or does it vary from API to API? Any help is greatly appreciated. Are there any tutorials or reads you recommend to better understand how to deal with HTTP requests?
Thank you!
Based on This article and some points of others, you could find out about differences between HTTP header & HTTP parameter ,and and also Body:
Header:
meta data about the request
HTTP Headers are NOT part of the URL
if it's information about the request or about the client, then the header is appropriate
headers are hidden to end-users
globally data
restrict Dos-attack by detecting authorisation on it's header, because a header can be accessed before the body is downloaded
Param:
the query params are within the URL
like this "tag=networking&order=newest"
if it's the content of the request itself, then it's a parameter
The product id and requested image size are examples of "some detail" (or parameter) being supplied as part of the content of a request
parameters can be seen by end-users (query parameters) on URL
Body:
data of business logic
important information
unlike body, proxy servers are allowed to modify headers
data in specefic kinds of requests
you can pass token by body as encoding & decoding in servers
For a full and correct understanding of these questions, RFC2616 recommend by Remy Lebeau is worth reading.
What exactly is the difference between the body and the data?
If you are reading some blog, the body (HTTP body) is be used to transfer data (probably in JSON format). The body carries data, in another way, you get data from body.
Are they the same thing?
So they are not same at all.
Or are headers the same thing as the param?
Header (HTTP header) is related to body, they are part of the HTTP message.
As param, it's usually refer to http request param, which usually looks like the following part of the question mark
url?paramName=paramValue¶mTwo=Value2
When authentication takes place, are the username and password params
or headers or does it vary from API to API?
They vary for different API's, normally not in param, probably in body of a post request.
Again, start from the RFC2616 would be a good choice.
data is not a HTTP specific term. data can be anything.
a 'parameter' is also not a HTTP specific term. Many web frameworks might consider parameters everything behind the ? in a url, but this is not an absolute truth.
usernames and passwords sometimes appear in the request body, sometimes in headers. In web applications they typically are in the request body, but certain types of authentication systems place them in the Authorization header.
I have a URL abc.com/#cancel. In my servlet I need to store #cancel for future use. I have already tried HttpServletRequest getRequestURI() and few other options. But don't see this value in request object. How do I get this value.
In my application I am using GWT which uses rpc calls and rpc request is made based on the hash tag value. eg: mydomain.com/#profile, forwards the request to profile.rpc. In my case I am intercepting this call with a filter which does some basic check and then I want to forward the request again to mydomain.com/#profile. but I am not able to find #profile in request object. Hope this explains my question and what I am looking for.
You cannot get the fragment part of a URL server side, as the browser won't send it to the server.
Eg: User click a link to http://www.example.com/foo#bar. Browser connect to www.example.com and send:
GET /foo HTTP/1.1
Host: www.example.com
Hash(#) is used to separate fragment from Url. Fragment is an optional part of the URL and is used to address a particular part of a resource.
please see below links
http://www.skorks.com/2010/05/what-every-developer-should-know-about-urls/
URL fragment (#) allowed characters
List of valid characters for the fragment identifier in an URL?
request.getRequestURI() will gives you the url eg:abc.com/#cancel.
String url1=request.getRequestURI();
url1.split("/");
Found out that fragmented URL doesn't come in request, when we do response.sedRedirect(), browser doesn't remove the fragmented part from browser URL bar. But not sure how this happens. Anyways in my case instead of posting request to another JSP and then submitting the form to different URL, I am directly doing response.sendRedirect(), which doesn't remove the fragmented part, so its working now :)
I have been reading on SAML 2 binding mechanism. It says below :
HTTP REDIRECT VS. POST BINDINGS: Both SPs and IDPs can transmit and receive messages using redirect or POST bindings. Due to the limitation of URL lengths in certain scenarios, HTTP Redirect is usually used when passing short messages, and HTTP POST is used when passing longer messages.
I am unable to understand how a response with the same length can be longer in redirect than it is in post. I think I am missing something very basic. Could anyone help to clear that ?
Redirects utilize the querystring to pass data, which has a size limitation that is not present in a post.
From w3schools:
Example Get:
/test/demo_form.asp?name1=value1&name2=value2
Example Post:
POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2
the parameters for a get are located within the URL itself, which has a size limitation of 2083 characters (there is some variation to this number). For a post, the information to go along with the post is in the actual body of the message, rather than the URL.
Basically you get more "room" in a post, as you're not going to hit a size restriction on URL because your information is in the body - unless your URL is already that long which would mean it'd be an issue for gets or posts.
Why is the redirect url is of longer length?
I think you might be misunderstanding, it's saying you get less room for a redirect than a post, not more/longer. Gets have a size restrictions, posts do not, or at least it's a configurable setting on the server and has a larger "higher end" than a get request would.
I want to redirect my users browser using HTTP code 303 to a GET URL that I secure using HMAC. Because the request will come from the users browser, I will not have fore-knowledge of the request headers. So I am generating the HMAC hash using the values of the HTTP method and URL only. For example, the URL I want the browser to do to might be:
GET /download
?name=report.pdf
&include=http://url1
&include=http://url2
This create report.pdf for me, containing the contents of all the urls specified using the include query param.
My HMAC code will change this URL to be
GET /download
?name=report.pdf
&include=http://url1
&include=http://url2
&hmac-algorithm=simple-hmac
&hmac-signature=idhihhoaiDOICNK
I can issue HTTP 303 to the user using this URL, and the user will get their report.pdf.
As I am not including the request headers in the signature, I am wondering two things:
1) Can a would-be attacker take advantage of the fact that I am not signing the request headers?
2) Is there a better way to achieve what I am trying to do?
When I realised that what I am talking about here is a signed URL, I checked the Amazon Docs and found "REST Authentication Example 3: Query String Authentication Example" in this document: http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html.
This example is about a signed URL for use through a browser. About signing the headers, the document says:
You know that when the browser makes the GET request, it won't provide a Content-Md5 or a Content-Type header, nor will it set any x-amz- headers, so those parts are all kept empty.
In other words, Amazon leave the headers out of the signature.
Amazon make no mention of potential security holes, so until I hear otherwise (or get hacked :) ), I will assume my approach above is fine.
Is this possible.. for example, imagine I respond to a request with a 302 (or 303), and I inform the browser to do a request to a given location.. is there a header that I can send with the HTTP 302, so that the subsequent request from the browser would include that header?
I know I could do this with the location header, as in redirect and specify the information in the url as a query string.. but I'm wondering if there is a better way.. it seems that it should be a legit scenario..
'Content has moved, go here .. oh and you'll want to take this with you to give to the redirect location'
I'm guessing a big fat no!
Thanks in advance.
Edit
The reason for this is in respect to PRG patterns, where you have a GET url and POST url, given that you post data and it isn't acceptable, the server redirects you to the GET, and does some 'magic' in order to 'send data' to that GET, using most often session state to store a variable.
However this can breakdown in scenarios where many of these PRG requests are happening, granted this isn't a common scenario and generally nobody need worry about this.. but if you do- you'll need a way to identify the requests, this can be done with query string parameters send in the 302.. so that a specific entry can be put in session state according to that request.
The question was regarding trying to remove the 'request key' from the url, and making it more implicit.. cookies 'appear' to work, but they only make the window for screw ups smaller.
It would be great to say when you go the 'location' i've specified, send these parameters.
Edit
Just to note, I'm not trying to get the browser to send arbitrary headers to the location, but if there is ANY headers designed to hint the context of the request (like the querystring parameters could).
A redirect response itself doesn't contain any data. You can redirect using a URL with query parameters, but the new "location" will need to know how to consume those parameters.
No, that’s not possible. You cannot force the client to something. You just can say “this is not the right location, but try that location instead”. But it’s not guaranteed that the client will send the same request or another request to that new location. And telling the client to add a specific header field in that subsequent request to the new location is also not possible.