I have a web application, on which we currently implement XSRF protection.
From what I gather, XSRF attacks work this way:
the attacker finds out how the client communicates with the server of
the web application, i.e. how its HTTP requests are formatted
the attacker rewrites (forges) a http request that would order the
server to do what the attacker wants
all the attacker now lacks is an authentification on the server
the attacker tricks people into loading a webpage that sends his
forged request. Out of the people who get tricked, those who
happen to be currently logged in the application will unwillingly
provide the forged request with the credentials it needs to be executed
by the server.
To test our website, I looked at the POST HTTP requests the client sends to the server to give it orders (using F12 in Internet Explorer), and forged one myself.
It looks like this:
https://mywebsite/Camp.aspx?
EventTarget=SaveButton
&TargetField=I+am+the+king+of+the+world
First line is the URL seen in the browser (minus the "?"), second line is the action to be executed by the server, 3rd line is the field I want to update.
Then I logged on the website and tested my forged request in 2 ways:
A) I simply open a new tab in the browser, paste the forged URL above and click enter
(tested with IE and Chrome)
B) I open in another tab a page with content:
<html xmlns="http_www.w3.org/1999/xhtml">
<body>
<form method="post" action="https://mywebsite/Camp.aspx">
<input type="hidden" name="EventTarget" value="SaveButton">
<input type="hidden" name="TargetField" value="I+am+the+king+of+the+world">
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
(tested with methods GET and POST)
I would expect both tests to be identical but to my surprise:
test A opens the target page on the website and actually updates the
target field
test B opens the target page on the website but does not update
the target field
I have 2 questions:
Why do test A and test B bring different results?
Test B definitely is a valid CSRF Attack Test (even though an
attacker would rather want to do the action without opening the
page), is Test A also valid?
Thanks!
Solved the Problem myself.
I had obviously posted a simplified version of the request. The real request contained signs that need to be URL-encoded. Here it was the sign "$", which encodes in URL as "%24".
So if the direct URL is
https://mywebsite/Camp.aspx?
EventTarget=abc%24def
then the corresponding HTML form should be
<html xmlns="http_www.w3.org/1999/xhtml">
<body>
<form method="post" action="https://mywebsite/Camp.aspx">
<input type="hidden" name="EventTarget" value="abc$def">
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
Related
Can someone please tell me what happens behind the scenes in the following case (i.e. explain the whole technical process)?
<form method="get" action="#">
<input type="text" name="d" value="flowers">
<button type="submit">send</button>
</form>
In this case after one has clicks on “send” a new webpage opens saying: "You have searched for "flowers" " and an image of some flowers below.
In the browser tab right after the URL of the newly opened page there is
“/?s=flowers”. What is that?
Thank you in advance for your answers!
When you click Send, the page data specified in the form information and values is passed to the server via HTTP.
The /?s=flowers is the GET data being passed back to the server. Although, based on the form code you've provided, the "name" of that value is d. So the URL would actually have /?d=flowers
The PHP or server side language then handles that information to do specific tasks. It can access the info using the name "d". This method of sending data is called GET, there are also other ways of doing this. The most common, POST, does not display the data in the URL and send the data through HTTP headers.
The code you've shown has an action of "#" which means the HTTP method is being sent the same page. Meaning this page code would have some PHP located in it. This can also be done by using a seperate file, such as action='send.php'
According to the HTML book which I am reading (and according to here: http://www.w3schools.com/tags/att_form_action.asp) it says that in the case of forms:
<form action="/login/" method="post">
'action' specifies where to send the form data when a form is submitted. The syntax for it could be
<form action="URL">
Now, in the book I am reading, it also talks about a hidden 'next' variable, like so:
<form action="/login/" method="post">
<input type='hidden' name='next' value='/' />
<input type='submit' value='login' />
The book I am reading states that
The form contains a submit button as well as a hidden field called 'next'. This hidden variable contains a URL that tells where to redirect the user after they have logged in.
From my understanding, doesn't 'action' either way tell specify where to redirect to after the form has been submitted? So isn't having the hidden 'next' variable not necessary because 'action' already tells where to redirect to? Which takes priority if action and next are different URLs? Does it redirect to the URL in action or the URL in next?
First up the action attribute has nothing to do with redirection.
When you click a submit button in a form the browser sends an HTTP request to the server, specificaly to the resource mentioned in the action attribute, using either get or post. What happens next is entirely dependant on what you are using server side.
As far as I am aware the presense of a Next property in the request has no special meaning.
Normally when a form is submitted one of two things will happen
The server does some process then return an HTTP Response. This will show the action url in the address bar of the browser
The server does some processing then redirects the user to a new page. This is usualy programmed by you the programmer and does not happen automagicaly. In php you would use http_redirect(someURL). The next hidden field could be used to hold this URL but it won't do anything with it by itself.
On a technical note, http redirects, be they with asp, php, etc cause, an additional round trip to the browser. So in the case of the redirect above, an HTTP Response is send to the broswser with a header indicating to redirect and where to direct to. The browser will then send a new request to the new location. This is why the new address appears in the browser address bar.
Action url is where the page will be redirected to, by default. The value of next has no effect unless you have server side code to do that. Even if you do write code, the redirect will first go to action url and then to any other url you have changed.
Just to give a background. I wrote the below code in a normal html file. With no server or anything running on my system. I created a file on the desktop and wrote the html code in there.
First Method
<form action="http://www.google.com" method="GET">
<input type="submit"/>
</form>
Second Method
<form action="http://www.google.com" method="GET">
<input type="button" onclick="myMethod()"/>
</form>
<script>
function myMethod(){
$.ajax({
data:'',
type: 'GET',
url: 'http://www.google.com',
success: function(response){
$(".popupdiv").html(response);
}
});
event.preventDefault();
return false;
}
</script>
When I do the first method, on clicking the button, I get taken to the google.com but by second method, nothing happens. Even my (chrome)console does not show any error.
What is happening and what is the difference?
Even my (chrome)console does not show any error.
This seems unlikely.
Mine shows: Uncaught ReferenceError: $ is not defined
If I add jQuery, it shows: XMLHttpRequest cannot load http://www.google.com/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://run.jsbin.com' is therefore not allowed access.
Even if that wasn't the case, $(".popupdiv") won't match anything in your document.
What is happening and what is the difference?
In the one case, you are telling the user's browser to just go to Google.
In the other, you are telling the user's browser to fetch some data from Google and make it available to you. Since the content a website shows can depend on the browser sending credentials (in Google's case it actually does), this would be a serious security problem if it was possible.
See also: Ways to circumvent the same-origin policy.
the action normally sends you to it's value "mostly the name of a file or a url"
but when you're using a get method this only send a request to load the data from the file or the url given, try your second code with an Xml or a Json file to understand it more.
I'm working in an app with Phonegap. I did many GET requests for getting JSON files and they work nicely, but when I try to do the same but with a POST request, I have no callback and in the server I get error 400 (I don't even send anything to the server).
So I minimized my app and I included this in a plain HTML:
<form action="https://edge.suitepad.de:442/api/v1/8b17ec5acab7537b/orders/a4054d5fe4184431f55aca69cca9a7ef/purchase" method="post">
<input type="hidden" name="order" value='{"currency":"eur","order_items":[{"id":265,"quantity":5}]}' />
<input type="submit">
</form>
Does this work for you? Do you receive any callback having this form in an app with Phonegap?
Thank you.
Post requests work just fine from phonegap - the bad request error is something specific to your combination of data and server setup.
The html you show certainly won't fire a callback though - as soon as you click submit, it is loading a page from the server and the phonegap page containing the callback is gone.
An exception was thrown in my application, but the HTTP_REFERER was null, which seems strange in this case. I'm wondering if you could answer a quick question:
So I've got this form:
<!-- mysite.com/index.html -->
<form action="http://mysite.com/somewhere/else">
<input type="submit" />
</form>
When someone submits the form, I am expecting that the $_SERVER['HTTP_REFERER'] will be set to /index.html. Is that true?
$_SERVER['HTTP_REFERER'] is the value of the optional HTTP Referer header. This header is set by the browser.
The browser can opt to not set it or to lie about it, such as Firefox's RefControl addon does. Thus, you cannot rely on it to be present, or even accurate.
If a browser does give it, it will most likely not be /index.html, but rather http://www.mysite.com/index.html
Yes. I just tested it with both HTTP POST and GET and the Referer header was sent by the client (Google Chrome) both times.
This might be browser specific behaviour though.
EDIT:
In case anyone cares, here's a simple way to test it in PHP:
<?php
echo $_SERVER['HTTP_REFERER'];
?>
<form method="post"><input type="submit" value="Submit"></form>
<form method="get"><input type="submit" value="Submit"></form>
I believe that if you type in the URL, the browser won't set the referrer, but if you come from another page (click through or form post), the browser should set the referrer variable. This variable should be read and parsed by PHP.
Yes, when the POST is sent but not necessarily when the page is first loaded. You can always verify this by looking at your logs ('tail -n 10 file.log' will give the most recent 10 entries). The referrer part (for a dummy PHP form site.com/php-form/) below is in bold:
192.168.1.10 - - [16/Apr/2008:16:12:36 +1200] "GET /php-form/ HTTP/1.1" 200 2014 "http://www.referringsite.com/" Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.8 (like Gecko)"
Referrer is usually sent, so, you can expect it.
But you cannot rely on it, as it's only on the client's will - to send it or not.
And many clients don't.
http://php.net/manual/en/reserved.variables.server.php
'HTTP_REFERER'
The address of the page (if any) which referred the user agent to the current page. This is set by the user agent. Not all user agents will set this, and some provide the ability to modify HTTP_REFERER as a feature. In short, it cannot really be trusted.