- Is it a potential security risk to leave form inputs without values if I'm only checking isset?

[appobs]

  I read ages ago (and checked to see if it's true, it was and given how it works, it must still be) the end user can alter the value of any form field, using Firebug or similar, before submitting it.



  Two things I've figured out today:

 1) a form input doesn't need a value - doesn't even need the attribute - if you're only checking whether the POST var isset and the actual value isn't important

 2) Although it appears not to matter in the example I'm working on now, if the script doesn't check what the value is, and potentially sanitise it, the user could submit the form with any value, true, false, malicious, idk...


  So my question is: is this one of the ways malicious bad things can happen and do I *have to* specify a value, not because the script won't work without it, it does, but because in the real world it opens a security door if I don't check for malicious script by saying "if value not as expected, script has to die".



  Having formulated the question properly and thought about it I can't imagine simply making a form, without obvious connections to anything important, could be a problem in the way I'm asking about but I asked it now so

Edited July 3, 2014 by appobs

[Jacques1]

The idea of “sanitizing” user input is bullshit and downright harmful.

 

Input by itself doesn't do anything. It's just data. The problem is that many programmers fail to use the data properly. For example, if you naively insert the raw user input into a query string, then you have an SQL injection vulnerability. This is not a problem of “evil input”. The user hasn't done anything but submit a bunch of text. It's your fault that you have inserted this data into a query instead of using a prepared statement.

 

So, no, you don't need to validate the data. You have to treat it correctly and not do any strange things with it. This actually applies to all data, not just user input. To stick to the previous example: If you need to pass values to a query, you always use a prepared statement, regardless of where the values come from.

 

Treating validation as a security feature is actually a huge misunderstanding and can lead to serious vulnerabilities. Just because the input is formally valid doesn't mean it's harmless in every possible context. For example, a perfectly valid e-mail address may very well carry SQL fragments for an injection attack.

 

The sole purpose of data validation is to ensure formally valid data. If you need that, go ahead. But this is not a security feature.

Edited July 3, 2014 by Jacques1

[appobs]

What a warm and helpful welcome.

 

Lemme ask the question more better this time now I've had longer to think about it:

 

"If you don't connect a form to anything (e.g. a database) is there anything malicious a user could do with a form input? Is an otherwise completely innocent HTML form a potential 'way in' for an attacker?"

 

 

 

As I said, after some thought, I can't imagine there is - HTML itself would have to have a vulnerability which I don't thnik is possible because it just doesn't "do" very much.

[maxxd]

So what exactly is the purpose of the form? If it doesn't really do anything, why is it there? What is the not much that it does? For instance, a contact form may not insert any data into the database, but a malicious user could inject to: and from: headers into the comment section and use your contact form as a spam launcher to send mail to users. If the actual body of the spam mail contains malicious code, then yes. This could be a problem.

 

I think what Jacques1 is saying is that any and all data needs to be carefully considered before anything is done with it, regardless of its eventual purpose - whether it's stored in the database, displayed to the current user, or e-mailed anywhere. I don't know that you need to validate the contents of the specific form element because I don't know the purpose of your form, but you should definitely handle all the other data - which I'm sure you're considering, given the fact that you've asked this question.

 

Jacques1, please correct me if I'm wrong regarding my understanding of your post.

[kicken]

"If you don't connect a form to anything (e.g. a database) is there anything malicious a user could do with a form input? Is an otherwise completely innocent HTML form a potential 'way in' for an attacker?"

Whether or not someone can do something malicious with an input is entirely dependent upon what you decide to do with that input and how you treat it. If all your doing is an isset() check then it doesn't matter what they input because you are not actually using it anywhere, all you're doing is testing if some input was sent or not.

 

For all input what you need to do is make sure you consider the context in which you will be using that input and ensure you apply the appropriate safe-guards, such as escaping (html), prepared statements (sql), new-line elimination (smtp/http header fields), etc.

[sKunKbad]

I find that in most cases client-side and server-side form validation are beneficial. Client-side validation through JavaScript can provide instant feedback to the user, and prevent a frustrating user experience. Server-side form validation can quickly eliminate problems where input data is not in it's correct form, and give the user a chance to fix it based on error messages that you can show.

 

For example, if the form expects an integer for a value, both client-side and server-side validation could let the user know there is an error because they input the letter A. This field could also be required, so if left empty, both validations would have let the user know. JavaScript can be disabled, so it should never be the only validation. It should just be used to enhance the user experience. Server-side validation cannot be disabled, so it's the essential validation for your form.

 

The responses above do correctly state that security issues are based on the way you use the data, but when you restrict the incoming data based on a tight set of rules and filters, the data can actually be expected to function correctly for its intended use. You can't be too safe. You want to validate the incoming data, AND use it in a safe way.

[KevinM1]

We can't give a firm answer because we don't know what you want to do with the data that's being passed in by the user. Any danger is predicated on the data's intended use. Like Jaques colorfully said, form data is simply data. It's not inherently dangerous, even if it contains a string that could potentially be used as a SQL injection or XSS attack. It's how that data is used that determines whether you're flirting with danger.

 

Put another way, there's no one-size-fits-all rule to making something safe. It depends on what you want your code to do.

[appobs]

The point is there is NO data being passed in by the user - I was making a UI thing to try out creating and deleting files and dirs and was tidying up my code when I realised the value in the form inputs was redundant. So I took them out, I even took out the attribute itself so:

<input type="hidden" name="test1" value=''></form>

Becomes:

<input type="hidden" name="test1"></form>

Not a vast difiference but it brought up a question - I wanted a final answer on what is or isn't a "security risk".

 

Sounds like you have to make a program that actually allows bad stuff to happen. I've assumed in the past that there are what people call "vulnerabilities" waiting to happen in systems such as HTML, java, javascript, php, databases and the programs end users use to interact with them.

 

1. I still think some of them do have vulnerabilities waiting to happen but that's what all the Java updates are about right?
2. HTML can't cause "security problems" though - it doesn't "do" anything

Are those two points correct?

 

It sounds like a programmer has to actually do something stupid (like allowing an end user to insert bcc into a contact form or something into a database ala little Bobby Tables). My concern is that I've been learning tutorial-programming which leaves out a lot of important real-world stuff... Who really uses "or die()" ?? Seems pretty useless to me - you'd always do something 'better' like send the user to an actual page or something - what's it REALLY for? But Tuts spatter it about allover the place, so do many scripts you get 'for free' on the internet.

 

It seems I've been assuming there's more mystery to "security vulnerability" than there actually is.

 

Anyway - my code - This is what I've been doing:

<?php 
$uRoot = "/home/username";
// Folder should have a convoluted name so unlikely to accidentally delete important other stuff
$folder = "folderWithNameUnlikelyToEverBeRepeated31Bd46";
?>

<!-- Reset and Test button -->
<button onclick="location.href=''">reset - onclick</button>
<form action="" method="post" id="formTest">
	<input type="hidden" name="test1"></form>
<button form="formTest">Test 1</button>
<?php
isset($_POST['test1']) ? print "Test 1 button has been pressed!" :	print 'Test 1 button not yet pressed';
?>
<hr>



<!-- NOW THE "MAKE/DELETE FOLDER USING BUTTONS" THING! 
=======================================================
some examples: http://davidwalsh.name/basic-php-file-handling-create-open-read-write-append-close-delete
-->

<!-- MAKE THE FOLDER -->
<form action="" method="post" id="makeFolder">
	<input type="hidden" name="makeFo"></form>
<button form="makeFolder">make the unlikely-name folder</button>
<?php
isset($_POST['makeFo']) ? mkdir($folder) : print '';
?>

<!-- REMOVE THE FOLDER -->
<form action="" method="post" id="removeFolder">
	<input type="hidden" name="removeFo"></form>
<button form="removeFolder">remove the folder</button>
<?php
isset($_POST['removeFo']) ? rmdir($folder) : print '';
?>

<!-- MAKE A FILE IN THE FOLDER -->
<form action="" method="post" id="makeFile">
	<input type="hidden" name="makeFi"></form>
<button form="makeFile">make a file in the folder</button>
<?php
isset($_POST['makeFi']) ? fopen($folder . '/file.txt', 'w') : print '';
?>

<!-- UNLINK ALL FILES IN THE FOLDER -->
<form action="" method="post" id="unlinkFilesInFolder">
	<input type="hidden" name="unlinkFis"></form>
<button form="unlinkFilesInFolder">unlink the file(s)</button>
<?php

if (isset($_POST['unlinkFis'])){
	$files = glob($folder . "/*.txt"); // Leave just .txt for safety
	foreach($files as $file){
		unlink($file);
	}
}
?>

<br>
<?php
is_dir($folder) ? print "Folder exists<br>" : print "Folder isn't there<br>";
file_exists($folder . '/file.txt') ? print "File exists<br>" : print "File isn't there<br>";
?>

Edited July 5, 2014 by appobs