I have a simple contact database application written in php (PDO) and MySQL. It is a single file with a switch case statement. Default shows the table of contacts, case: add, edit, delete etc for the functions. All MySQL statements are prepared statements in PDO.
My question is:
Is it better to use a html link with parameters to move about or is it better to use a POST form with the parameters as hidden fields.
e.g. in the table listing the contacts, within each row is it better to have a link:
edit
and get the 'mode' for the switch and the parameters from a $_GET statement
or is it better to have:
<form method="POST" action="">
<input type="hidden" name="mode" value="edit"/>
<input type="hidden" name="contact_id" value="321" />
<input type="submit" name="submit" value="edit" />
</form>
I am interested from a security point of view as well as a functionality point of view. I have looked for similar questions here and found only one with a single answer that said a form is better. It had no explanation and 4 upvotes.
Any information would be greatly appreciated.
Cheers.
It is definitely better to go with the form. Why? Well, the URL navigation would be submitted via GET requests, whereas the <form> submission is handled via POST. GET requests are exposed to the end-user, whereas POST requests are not. As Stated by TeamTreeHouse in the previous link:
Use POST when dealing with sensitive data.
Consider your former approach. A user sees index.php?mode=edit&contact_id=321 appear in their browser. If they were malicious, they would easily be able to make the correlation to index.php?mode=edit&contact_id=1. They could easily type that in their browser. Assuming you don't have any other authentication mechanics set up, they'd be able to go ahead and edit someone else's account.
The latter is slightly better. Although source code is not as obvious as an exposed URL, anyone is still able to view it, and find your hidden 321 contact. You might think that a malicious user cannot edit hidden form fields like they easily could with a query string, though this is not the case. They can download and create their own copy, simply replacing the action parameter with your own, thus submitting tampered data. There's even browser addons for this, making it even easier!
To get around this, you're looking to combine the <form> method with an authentication token. Generate a token that verifies the integrity of the form, ensuring that the form is not manipulated after being generated. It depends on exactly which language you're using on the back-end as to how to generate the token, but there's a great article for JSON web tokens here.
Upon form submission, check the token matches what it was upon generation. If it matches, all is well, so you proceed. If it doesn't, the form has been manipulated, so you deny submission.
For further information, I recommend checking out OWASP's article on Cross-Site Request Forgeries.
Hope this helps! :)
My sign up form works on HTML5 inputs (email,password,username..) also using patterns . Do i need to check the inputs with php to before inserting them in to mysql?
Absolutely.
Remember that anyone can send raw HTTP requests and fill in the fields with any data they like. Never trust user input; always check it server-side.
For our last week in school (finals next week) our teacher decided to give us a crash course in Perl. We talked about all the differences we would encounter if we used Perl and then we started talking about "spoofing".
We were given an HTML example where a user could input their first and last names. Of course our example already had Mickey as the first name and Mouse as the last name.
<form action="action_page.php">
First name:<br>
<input type="text" value="Mickey">
<br>
Last name:<br>
<input type="text" name="lastname" value="Mouse">
<br><br>
<input type="submit" value="Submit">
</form>
At the end when you hit submit you were redirected to a new screen that said your first name is Mickey and your last name is Mouse.
Our teacher said "spoofing" is when you change the method = get in the URL so instead of having
firstname=Mickey&lastname=Mouse
you would enter something like
firstname=baseball&lastname=bat
That would instantly alter the intended command and you would end up getting first name as baseball and lastname as bat.
This all sounds pretty straight forward, until he said he wanted us to write a program to prevent spoofing without using a post method.
Instead when a user attempts to spoof the system we're supposed to print out some anti-spoofing comment.
Unfortunately, we never really talked about spoofing aside from the examples. I've attempted to Google spoofing to see some example code, or at least understand this concept, but I haven't had much luck, or I haven't looked in the right places.
So I thought I would ask here. Can someone who is decent at Perl direct me towards basic anti-spoofing programs and content, or at least explain and show how spoofing is supposed to work.
What you need to do is to authenticate the data in the query string, and validate it when you receive it. There is a standard tool(set) for this: a cryptographic Message Authentication Code (MAC).
Basically, a MAC is a function that takes in a message (any arbitrary string) and a secret key, and outputs a random-looking token that depends, in a complicated way, on both the message and the key. Importantly, it is effectively impossible to compute a valid MAC token for a modified message without knowing the key.
To validate a query string (or some other data) with a MAC, you'd basically follow these steps:
Encode the data into a "canonical" form as a string. For an HTTP URL, you could just use the query string (and/or the entire URL) as it is, although you may wish to normalize it e.g. by %-decoding any characters that don't have to be encoded, and normalizing the case of any %-encoded values (e.g. %3f → %3F).
Alternatively, you could decode the query string into, say, an associative array, and serialize this array in a format of your choice. This can make it easier to combine parameters from multiple sources (e.g. hidden form fields), to add extra data fields (see below) and to choose which fields you want to validate.
Optionally, combine the data with any additional information you wish to associate it with, such as a user ID and/or a timestamp. (You can either transmit the timestamp explicitly, or just round it down to, say, the last hour, and check both the current and the previous timestamp when validating it.) Changing any of these values will change the MAC output, thus preventing attackers from e.g. trying to submit one user's data under another user's account.
Store a secret key (preferably, a securely generated random value of, say, 128 bits) on the server. Obviously, this secret key must be stored so that users cannot access it (e.g. by guessing the path to the config file).
Feed the canonically encoded data and the secret key into the MAC algorithm. Take the result and (if your MAC library doesn't do this for you) encode it in some convenient matter (e.g. using the URL-safe Base64 variant).
Append the encoded MAC token as an extra parameter in the URL.
When you receive the data back, remove the MAC token, feed the rest of the data back into the MAC generation code as described above, and check that the resulting MAC matches the one you received.
MAC algorithms can be constructed from cryptographic hash functions like MD5 or SHA-1/2/3. In fact, a basic MAC can be obtained simply by concatenating the secret and the message, hashing them, and using the result as the token.
For some hash functions, like SHA-3, the simple MAC construction described above is actually believed to be secure; for older hash functions, which were not explicitly designed with this use in mind, however, it's safer to use the (slightly) more complicated HMAC construction, which hashes the input twice.
Alternatively, there are also MAC algorithms, such as CMAC, which are based on block ciphers (like AES) instead of hash functions. In some cases (e.g. on embedded platforms, where a fast hash function may not be available) these may be more efficient than HMAC; for a web application, however, the choice is essentially a matter of taste.
One difference between GET and POST is that the information for the former is passed in the URL itself. That means you can type what you like in the browser's address bar -- it doesn't have to have come from an HTML form. I think that's what is meant by spoofing here.
The most obvious protection is to calculate a CRC of all the protected fields -- in this case MickeyMouse -- and put that value in a hidden field of the HTML form sent out by the server. Then, when the request comes back, calculate the CRC of the same fields and check that it matches the value of the returned hidden field.
Of course that can be circumvented if the user works out how the protection functions and adds his own calculation of the CRC of his spoofed data as well. But this should be sufficient for a proof of concept.
If you want to detect if a user has changed a parameter in the querystring of a url after a form has performed a GET action, then generate a client side hash before the form is submitted. The hash would be based on the values of the form fields, and then compared to a recalculated hash based on the current parameter values on the response page. If the hashes don't match the querystring has been tampered with.
Here's a client side Crypto library to calculate the hashes https://code.google.com/p/crypto-js/
Note this is only for educational use, and wouldn't provide enough security in the real world, as a person could also discover the hashing key by inspecting the page source and use that to generate their own hashes.
A POST method wouldn't prevent spoofing anyway. POST and GET do almost exactly the same thing - they send plain text encoded variables to a web server.
They're insanely easy to "spoof" - the point isn't the spoofing, it's that you shouldn't trust "user input" like that, ever.
I would suggest in the case of the names, it doesn't matter. So what if I fudge your web page to "pretend" I am called "baseball bat" instead?
If it's important, like for example, ensuring I can only see my test results - then you need to handle the data processing server side. One method of doing this is via session tracking - so rather than including field in a web form, I instead use a "session token".
You would 'send' me a username and password - ideally using a hash to make it impossible to 'see' as you're sending it, or in your browser history. And then I would check it against my server, to check if that hash is 'valid' by performing the same operation on the server, and comparing the two.
So perlishly:
#!/usr/bin/perl
use strict;
use warnings;
use Digest::SHA qw ( sha1_base64 );
my ( $firstname, $lastname ) = qw ( Mickey Mouse );
my $timewindow = int ( time / 300 );
my $token = sha1_base64 ( $timewindow.$firstname.$lastname );
print $token;
This produces a token that doesn't last long - it changes every 5 minutes - but it's extremely difficult to tamper with.
The reason for including the time, is to avoid replay attacks, whereby if look in your browser history, I can find "your" token and reuse it. (That's probably the next question after the "spoofing" one though :))
If you sent the parameters with the token, bear in mind that it's actually quite easy for a malicious actor to perform the same calculation themselves, and send some completely faked credentials and tokens.
This is something of a simplistic example though - because really, faked parameters shouldn't matter, because you shouldn't trust them in the first place. If 'Mickey Mouse' is valid, and 'baseball bat' isn't, then your server should detect that when processing the form, and discard the latter, which makes the whole 'form spoofing' thing irrelevant.
The question is rather narrowly phrased, so this answer might not quite address what you're asking. But as a matter of policy, if you don't want your users to tamper with your data you should not give them custody of it. Why are you relying on the query string for the user name if the server already knows it? Rely on the client for authentication and for new information, and rely on your records for any information that should stay beyond the user's control.
POST requests can be crafted almost as easily as GET requests, and cryptographic protection, even when it is secure, is only useful to the extent that the client cannot access
the encrypted data; so why transmit it back and forth?
I know it's a stupid question, but if I fill a form with various inputs but I don't give them a name and id, and I POST it to a php page, does the posted query contain any data?
If it does, then using inputs without names in a form result in a wasted sending time. am I right?
Is there any difference between GET and POST in this case?
I presume that the browser (client-side) determines what to send and what to not send.
I'll try to see what happens if i send a GET request: if in the browser bar appear something, some data has been sent.
But the POST method is still a mistery for me... when I have time I'll try to print the $_POST array. thanks for the "input" #MattP
I update my question after somebody attack: I printed down the result of $_POST and $_GET, but still, I think the only answer to my question is to check the weight of the data, not the things recognized by the server. If i send unnamed data to the server, the server may discard that ad take only the ones with the name.
(sorry for the bad english)
No, they won't get the data. id is optional, but for PHP to do anything it requires the name attribute.
Is there any way to send data from one HTML page to another using basic HTML without using JavaScript and PHP?
It's easy to "send" data:
Send
but there is no way for the receiving page to parse it without a server-side application or JavaScript. (Or Flash, or a Java applet, or an ActiveX control....)
html only purpose is to show content. It is not designed for getting and passing data. you need server side script to do that.
Good answers. Pekka and Andre really nailed it.
In order to pass data from HTML form fields to your web application:
1) You can manually build a link with query string variables (basically Pekka's example)
Submit
2) Or, to retrieve data typed in by the user (which is typically what you want), you can use the GET method
<form action="signup.pl" method="get">
Name: <input type="text" name="name" />
<input type="submit" />
</form>
Either way, you end up with a post to the web server with the same URL (provided the user typed "john"):
http://www.mycatwebsite.com/signup.pl?name=john
(or you can use POST instead of GET, but then query string variables don't show up in the URL)
But in order to read and process it, as already mentioned, you need a server side programming language.
Even the first dynamic websites back in the 90's used CGI Perl scripts, or even ANSI C, to process data. Here's a simple Perl example:
HTML Forms POST, GET
Now of course there are many web application languages (and frameworks) to choose from, such as PHP, Java, ASP.NET, Ruby, Python, etc. But they all adhere to the CGI convention of passing data back and forth (CGI Request/HTML response) between the web server (Apache, IIS) and the web site.
Common Gateway Interface
Dynamic website
You can prompt the user to enter data with a <form>, and you can add GET-query-parameters to your URL (index.php?foo=bar). But to work with the received data, you will need to use a programming language.
You can send data but can't process sent data. For it you must use PHP, javascript or something similar...