Preventing 3rd party HTTP POSTing to a php site

[Red Squirrel]

This is just a random thought that popped into my head, I never even thought of validating for this. Wondering if this is a legit threat I should be mitigating against.

Say I have a form on my site to perform administrative functions or even something as simple as just a forum to post stuff. You have to be logged in to use it and it's just a rather standard form, does some basic validation and escaping of data to prevent SQL injecting but other than that fairly basic.

Nothing stops a malicious site from POSTing data to that form via javascript or other method so if you are logged in and happen to go to the malicious site it will then POST data as you. Can that be done?

What is a typical way of preventing this sort of attack? What I'm thinking of doing is when a form is loaded it will generate a random ID, store it in a SQL table with other data to identify the form/user, and then have it in a hidden field. So when you submit the form it also validates that ID.

Is there a better way or am I on the right track?

 

[DaveSimmons]

Cross-origin requests are blocked by default in browsers - https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

So the malicious site could not issue an XmlHttpRequest to benefit from the session cookie from your login.

The malicious site could do a POST server-side, but since reading the cross-site cookies is also blocked the server has no idea what value to use in the session cookie.

 

[razel]

At least with IIS, there are request filters specifically for this. It will not be perfect but will get the majority. I'm sure with php those exist as well. However the better solution is validation in your code itself. Often validating the input and enforcing strong types would be enough. We have written a safeSQL function during validation of user inputted strings that we have tuned over a decade.

 

[DaveSimmons]

Yes, you must never trust the form values sent to the server since the user can easily mess with those just using a browser.

My post above only covers the question about a different site hijacking the authentication state after a user has logged in normally.

As far as a random hidden value, you've just reinvented the "nonce", which is most useful against replay attacks - - https://en.wikipedia.org/wiki/Cryptographic_nonce

 

[Red Squirrel]

Good to know there's already some protection built into browsers for this. While googling this a bit I also found about the httponly feature on cookies, I should set that to true as well. It would stop any javascript from having access to cookies that have the flag set. At least as long as the browser honours it.

The particular app I'm working on now already has lot of validation not only as far as input sanitation but also requires the user's password so it would stop someone from submitting the form through XSS.

I may go ahead and add a random validation code anyway though, just for good measure. I wrote a form class that handles a lot of the repetitious stuff like generating input fields so it would be easy to implement into the class as a flag I can turn on/off.

 

[Merad]

The term you are looking for is CSRF (Cross-Site Request Forgery), and it works exactly as you described in your first post: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

AFAIK CORS doesn't really protect against CSRF. My understanding is that CORS prevents reading responses, not necessarily sending requests. The malicious site that POSTs to your server will not be allowed to see the response, but the server will have already processed the request.

I would imagine that by now most web frameworks have some tools to help mitigate CSRF. I'm most familiar with .NET MVC which uses a combination of tokens stored in cookies and hidden in form fields: https://docs.microsoft.com/en-us/as...nting-cross-site-request-forgery-csrf-attacks

 

[DaveSimmons]

^ good points. Browsers now block cross-origin requests, but not a form that auto-submits itself on page load.

I think a nonce would block that attack because the malicious site would not be able to scrape a page with nonce that is only returned to authenticated users. The scraping attempts would not be able to include the session cookie so the site being attacked should just return an error or login page.

(An attacker using their own login could see the source for the page, but the nonces would be for their current login, not ones generated for victims.)

 

[Red Squirrel]

Yeah think I will go ahead and implement the unique ID (nonce) feature in my form class then. I figure it won't hurt to have the extra protection. Interestingly I have a script where I will actually need to POST data from another site to another site, it will be how it communicates, and then that's what got me thinking that it could be used for malicious purposes too if done to a form that it should not be done to.

Now I'm actually curious if SMF (forum software) implements anything like this, I will have to check. Since say I am logged in as admin, and then go to a malicious site, it could potentially cause me to do some admin functions on the forum, for example, if there's no protection against it.

 

[TempAcc99]

Say I have a form on my site to perform administrative functions or even something as simple as just a forum to post stuff. You have to be logged in to use it and it's just a rather standard form, does some basic validation and escaping of data to prevent SQL injecting but other than that fairly basic.

You are already being vague here and yes this can be confusing with pure php. A form usually has 2 parts. What the user sees and need to fill out, eg. the code run on the client = browser and then what happens after submit, eg. the code that is run on the server.

Validation on client side is simply to prevent the mist obvious mistakes. But you need to validate on server. Don't do escaping to prevent SQL injection. That is 90ties tech... Use prepared statements. Escaping still needs to be done so that the attacker can't load JS code in your DB that is then executed upon loading the page again (eg XSS). Note that the escaping could also be done on data display not when inserting.

Nothing stops a malicious site from POSTing data to that form via javascript or other method so if you are logged in and happen to go to the malicious site it will then POST data as you. Can that be done?

Simply said you can never trust the data that the server receives and it must always be validated. Having to be logged in obviously helps to mitigate a lot of attacks but since you wrote HTTP (and not HTTPS), replay attacks or stealing the session cookie are straight forward. In the end security has a cost and how much you need depends on the value of what you are trying to protect.

What is a typical way of preventing this sort of attack? What I'm thinking of doing is when a form is loaded it will generate a random ID, store it in a SQL table with other data to identify the form/user, and then have it in a hidden field. So when you submit the form it also validates that ID.

Is there a better way or am I on the right track?

If you use HTTP, the random ID can simply be read by the attacker and used to post data (if he posts before you). Of course it increases security (google for nounce) but the only real solution to being secure is to use https.

 

[Red Squirrel]

Actually can sites read data from other tabs? If yes, even if it's HTTPS wouldn't the data be decrypted at that point?

For this particular topic I'm not talking so much about validating form data from the user trying to attack the server, but rather ensuring that another web site can't submit the form for the user. Ex: I'm on my bank website, I open another tab to go google for something, I land on a malicious site, that site uses javascript to initiate a HTTP POST request to my banking site to transfer money to them. Because I'm logged in the POST could potentially go through if the bank website does not have any measures in place to stop that.

Though it sounds like browsers do have measures in place from what was mentioned earlier. Though I may still go with the unique ID idea so that you need to load the actual form (to create the ID) in order to submit it. But are you saying the malicious site would be able to read that unique ID anyway because the tab is open? Is this how Google, Facebook etc know what I'm doing on other sites?

 

[TempAcc99]

Actually can sites read data from other tabs?

Absolutely not unless the browser is fundamentally broken. Besides that I would never use online banking with serious 2-factor authentication.

However if you use http only, anyone can read out the data you are sending to the server and manipulate it. they can read out the session id and use that to submit their own requests. I mean it depends what you are trying to protect but anything on the open web? seriously use https.

 

[Red Squirrel]

Absolutely not unless the browser is fundamentally broken. Besides that I would never use online banking with serious 2-factor authentication.

However if you use http only, anyone can read out the data you are sending to the server and manipulate it. they can read out the session id and use that to submit their own requests. I mean it depends what you are trying to protect but anything on the open web? seriously use https.

Good to know that it can't be done, I always suspect it given all the weird stuff I see with FB and Google, like ads based on sites/searches that are open in other tabs, if I happen to disable adblock.

Will be using HTTPS, but what do you mean by anyone can read it if it's HTTP? Wouldn't that still require someone with access to the link to do packet sniffing at the time of a transaction? If I use the unique ID setup they would not be able to do a replay attack since the ID would have been invalidated once the form got submitted the first time. Of course all this is moot if they can also get the user's login info and then just log in as the user. But if someone has compromised my network to the point where they can stick a packet sniffer there I got bigger issues. Of course there's the NSA etc... so yeah HTTPS is important. I recently setup Lets Encrypt on most of my sites recently.

 

[TempAcc99]

Good to know that it can't be done, I always suspect it given all the weird stuff I see with FB and Google, like ads based on sites/searches that are open in other tabs, if I happen to disable adblock.

Well the track you accross boundaries in different ways. Cookies being the most simple one but there are other way like flash cookies or browser fingerprinting. The later being why JavaScript blockers are very helpful also for privacy reasons.

Will be using HTTPS, but what do you mean by anyone can read it if it's HTTP? Wouldn't that still require someone with access to the link to do packet sniffing at the time of a transaction? If I use the unique ID setup they would not be able to do a replay attack since the ID would have been invalidated once the form got submitted the first time. Of course all this is moot if they can also get the user's login info and then just log in as the user. But if someone has compromised my network to the point where they can stick a packet sniffer there I got bigger issues. Of course there's the NSA etc... so yeah HTTPS is important. I recently setup Lets Encrypt on most of my sites recently.

I mean it depends on your network setup. If this is just in your LAN it's obviously different from running an app on the web. If it runs on the web, http data can be read anywhere on the route to your server. So if your server is in US and the web user in China, you have a whole lot of network in between where someone can sniff. Like anyone can sit next to a highway and gather stats on the cars that pass.

 

[DaveSimmons]

That's a man in the middle attack, which is a valid security concern but a little off topic from the original question about a second tab on the user's own browser attacking his site.

It's true that using HTTPS is a very good idea for any sever that contains sensitive data or that is doing important work.

 

[Red Squirrel]

Oh right yeah I thought somehow being HTTP somehow increased the risk of the form being tampered which I thought was odd. I'm well aware that anyone on route can read the traffic if it's not encrypted.

So yeah I will probably go ahead and implement the auto generated ID in a hidden field idea for all my forms just to play things safe. Basically when a form is loaded a unique ID will be randomly generated and put in a hidden field and in the DB with other info like maybe user ID and name of form, and when the form is submitted it will check if that unique ID matches with an entry in the DB.