I have been reading and working with K Yanks “Build Your Own Database Driven Web Site Using PHP & MySQL” and have a question concerning security.
Kevin writes about how you can put malicious code into the adress field, by changing this:
http://localhost/welcome1.php?name=Kevin
To this:
http://localhost/welcome1.php?name=<b>Kevin</b>
He also explains what you can do to protect your site. But if you use POST that problem will never occur? If you click a link on my test site you get a url with the following form:
http://localhost/index.php?id=5
You cannot do anything bad with that URL or am I wrong?
Now, the $_GET[‘id’] is always safe and secured.
It contains 0 when it did not exist already.
Again, if the value was non-digit, it again is likely to be zero.
For the names, you can decide, whether to allow HTMLs, Quotes or not.
Normally, I do, for English names by:
Which means, remove anything other than alphabets, space, and a period.
However, you should have your own rules to sanitize all the inputs you will collect from the user. Plus, the client might have altered your form names using the javascripts. Make sure the take the sequence of Form Elements of your interests only, and not those added by the attacker.
Sanitizing the data gives injection/hack-proof experience. But you make them all.
No. All you need is a browser with the appropriate developer tools to access the headers and so POST is as easy to alter as GET is for those who know how.
There is no difference between GET and POST with regard to security because they exist for entirely separate purposes and so are not interchangeable when used correctly.
GET is used to retrieve data. That data is presumed to be relatively static and so the browser is supposed to cache the results so that multiple GET requests for the same data can read the cached copy rather than having to download the data again. Most requests for web pages use GET.
POST is used to perform updates. If multiple POST calls are made using the same data it is presumed that the result of the second call may or may not be different from the result of the first call. POST calls must always transmit to the server as that’s the only way of actually performing the update.
Almost all HTTP calls use GET since most requests are for web pages whose content will not change very frequently and so the downloaded data can be cached for if you ask to display it again (eg. by pressing the back button).
As there is never a situation where you are both updating data and not updating data at the same time there is never a situation where swapping between GET and POST is appropriate.
@Chroniclemaster1
Just don’t consider POST is safe. It is relative only.
If you type in the browsers address bar as the below code, you can take a control.
Address Bar: [ javascript:your_nasty_javascripts;return false; ]
You can add more form elements, or remove one. When security is an issue, these points may hit attentions.
Interesting, I’d always heard that POST requests were more secure because they’re more difficult to hack. With an alternate client (or possibly more know how than I’ve got) you can construct an HTTP Request manually and POST anything you want to attach the server or the app, but that’s fundamentally a fairly small (if nasty) group of people. A GET grabs its data out of the URL, so any moron with a browser can attack the server (often by just accidentally typing garbage into the address bar). What are the advantages of a GET?
Regardless, the one thing I totally agree on is that anyone who’s determined enough can feed whatever they want to you app via any HTTP method, so you’ve GOT to sanitize the incoming data, or at the very least some better escaping than magic quotes, that won’t even defend a DB.
You shouldn’t really use _POST to GET information though (if you know what I mean).
And you should never, ever trust user input, whether it’s from _GET, _POST OR _COOKIE.
So, to sum up: you should use _GET requests when fetching (i.e. getting) data, and all data should always be sanitized.