<form action="/path/hello.php" name='myForm' method='post'>
<!-- onChange="ajaxFunction();" -->
<input type= "text" name="user" id= "txtname" /><br />
<!-- <input type="text" name="user2" id="txtname2" /> -->
<input type='submit' name = "click" />
</form>
Noweveryone who looks at my html source code will know where this php file is located and will know how to call it. How can i stop this ?
If you handle the POST request to /path/hello.php properly, it shouldn't matter whether someone accesses it manually. Just make sure you are checking for things like the existence of $_POST['click'] and any other POST data you expect to exist, clean it, and proceed as normal.
If someone were to call /path/hello.php with spoofed POST data, then how would that be any different than them submitting your own form? There's no need to modify the script's visibility.
Furthermore, if your fear is that someone would be able to view the source of your PHP scripts--don't. The only thing a user would be able to see if they made an HTTP request to your PHP script would be the rendered HTML.
However, even if they could--why wouldn't you want someone to see your source (of course, barring situations where you might have sensitive configuration data within a PHP file)
You can't stop it. If you're going to tell the browser where the form is, you have to put the address in the HTML somewhere and once you do that anyone can see it.
It really shouldn't make any difference though, as your script should be able to cope with whatever values are sent to it. You can't blindly trust the data from the client in any case, so you need to verify the data sent is what you're expecting - no matter whether that's data sent by filling in your form as normal or someone calling it directly.
I can give a good example for why you would want to do this. You may have a service and offer it to a 3rd party, however in order to make this work there is some important configurable data that may come exposed. Here is an example
You own a website and let's say you want to create some type advertising campaign on your website but your "client" wants to advertise this the same thing on their website but the data needs to go into your email database.
you may not want them to know who you use
those services may require you to add account number or some type of identifying parameter towards your account.
May not be a big deal but still could be a security risk. So if you divert or mask it can prevent some of it.
There is no way to avoid this other than leave off action all together. The form will then submit to the current URL.
In any case, why are you worried about someone accessing the script? If you've written it correctly, no information should be exposed, and, no, they will not know how to "call" it - unless by calling it you mean simply accessing it in the browser. If by simply accessing it in the browser, sensitive information is displayed, you've got some serious problems on your hands.
I think your question is that by showing these paths that people will be able to actually view the source of the php file. That is not possible because it is being rendered by the php engine you are using. You have nothing to fear here.
Sorry, this isn't an answer, but a general observation on this same subject...
I have also experienced this and, seem to know where the OP is coming from...
I have seen a number of large CMS where form "actions" don't show the script... almost as if it points to a "friendly" URL...
Such as <form name="contactform" method="post" action="http://example.com/contact/send-contact">
As can be seen the extension is missing but the form is processed correctly...
I guess the htaccess could hide the extensions but some have a mix of visible URLs for standard pages and some "friendly" URLs for other content (including forms).
I'm not sure how these work...
It is sometimes considered best practice to keep .php files above the root directory to protect against the rare occurrence of php being configured incorrectly on the server and displaying php code to the client.
All you have to do is create a proxy script and post to that. I store the action in a hidden field so that I don't need multiple proxy scripts. I can't post the source code because I would be duplicating my answer on another post. You can find it here: https://stackoverflow.com/a/36941336/2452680
you can first give an action to page1 and in page 1 you can get the data and redirect and post the data to page2.
if you are using phpin page1 you can use curl and options to put data and execute it.
Related
I got a theoretic question.
If I use a form with GET method that is leading for an external PHP file (test.php),
I suppose anyone can find out what would be the result simply by viewing the source page, getting the variables (e.g., action="test.php" name="do" value="hello"), and then typing the URL with these variables:
....test.php?do=hello
I mean, he wouldn't have to actually click the button on the original page in order to find out what happens.
However, is there anyway to know what would be the result of a POST method button, without clicking it?
Your question has two possible meanings.
One is discover what the page does, what is the result of processing. That can be found by almost anybody with enough knowledge and tools to send a post request. There are a bunch of tools that allow you to do that. You can do it with plugins for your browser, security analysing tools like webscarab, programming languages using cURL, etc.
The second meaning is determining how the result was achieved. That, is not possible to know unless the source code of the processing file is accessed and analysed.
This is my first question on this site, so I'm going to try to be as specific as i can... By the way, excuse me for my perfect knowledge of English... which isn't perfect at all..
So what I was wondering is: do php variables persist if you change your page's content, using AJAX methods?
Let me explain: I want to code a web app which has to contain a main layer, containing a few tabs. The user has to be able to write stuff into text areas in one tab, switch the tab, and if he wants so, come back to the first tab to complete what he wrote before (also the app has to keep the php variables that it created previously right?). The app also has to put all the data, entered in all the different tabs, in one or many databases, when a summit button is clicked; so it has to access all the variables created before.
I just don't have any code at this moment, but I want to do a specification file before starting to code, because what I am about to do is kinda massive app, so i hope you will be able to explain me this point.
I still thank you for your help.
You would be best to consider the PHP script as a one-off thing. It does what it is asked to, then terminates. Nothing is preserved.
However, if you NEED to preserve something to pass back with an AJAX call, you can do it by including:
<INPUT type='hidden' id='my_variable' value='my_value'>
This can be referenced by the javascript that calls your AJAX PHP page and thus be passed back.
For what you require, as #AlexP said, you can simply change the visibility of each tab content area with:
<SPAN onclick='toggle(this.id)' id='tab_1'>Tab Name</SPAN>
or similar. Your JS function might include something like:
for(n=1;n<=numberOfTabs;n++)
{
document.getElementById("div_"+n).style.display="none";
}
document.getElementById("div_"+passedid).style.display="block";
though there are other ways of doing it.
Perhaps what you REALLY want to do is save the entered data into a database field frequently (or even continuously).
Just a general question. In terms of form actions if the form is submitting to it's parent page I realize that you can use "" or "#" to submit the form. Now my question is when writing a php page that has both the handler and the form I was told it was best to write a form action like this:
action="<?php echo $_SERVER['PHP_SELF'] ?>"
//or
action="<?php echo $_SERVER['SCRIPT_NAME'] ?>"
Now why would you need to add this inline script if you could have the form submit to itself using '#' or just simply not setting the form action. I'm just curious, as adding in that php does create bulky and messy looking form code (which is already bulky and messy looking).
I also understand that the alternate '#' and "" could be used in cases that you aren't using PHP, but I guess the real question is why add the PHP if you don't need it (in instances that the form is submitting to a php page).
thanks,
Brodie
Mahalo guys for all the responses. I realize that using the PHP code to generate the url is probably (in most cases) the route to take, as all it would take is for an update to a browser or to HTML in general to say "" and "#" are invalid operators for submitting to the root page. Also I know that the '#' is for referencing an anchor on the same page, but I figured I'd see what everyone's take on it was.
First of all the easy part: why put something into the value of action in the first place.
Well, the HTML 4 spec says (emphasis mine):
action = uri
This attribute specifies a form processing agent.
User agent behavior for a value other than an HTTP URI is undefined.
Therefore, while practically all browsers will end up submitting the form to the script itself, technically this is a happy coincidence that you should totally not rely on. However, this is not a problem for HTML 5.
In addition, # by itself is not a valid URI as per the W3C's definition, so that should be ruled out as invalid as well.
Now for the other half: how to get the current URL in PHP.
For basic usage, you can use either one of $_SERVER['REQUEST_URI'] and $_SERVER['PHP_SELF'] for this, depending on if you want to preserve any GET parameters in your current URL (PHP_SELF will not include them, but REQUEST_URI will).
In more advanced scenarios (e.g. writing code using a framework) it would be better to use the framework's own URL-generating utility functions to generate the URL for you (this would take routing etc into account, so is preferable).
Update: I misread the HTML 5 spec, which says you can leave the action blank.
Using # is not really the right way to do it, although it will work. You will find that the # on the end of a URL is supposed to be used to scroll the page down to an anchor on the page which matches it. Forms should use a URL in the action field. It's not wrong to do it any other way, but it's more to do with accessibility and usability (some JS librarys use the # url)
tl;dr - Leave it blank.
With modern frameworks and url rewriting, this is actually a bad practice. Your php script will more than likely be different than the URI path to access it.
Hi I have a web form that sends a string to one php file which redirects them to a corresponding URL. I've searched about web form hacking and I've only received information about PHP and SQL... my site only uses a single PHP file, very basic etc. Would it be open to any exploits? I'm obviously not going to post the URL, but here is some code I was working on for the php file:
Newbie PHP coding problem: header function (maybe, I need someone to check my code)
Thanks
From that little snippet, I don't see anything dangerous. "Hackers" can enter pretty much anything they want into $_REQUEST['sport'] and thereby $searchsport, but the only place you use it is to access your array. If it's not found in your array.... nothing much will happen. I think you're safe in this limited scenario ;) Just be careful not to use $searchsport for...... just about anything else. Echoing it, or inserting it into a DB is dangerous.
Uh, it really depends. If you are inserting data into a MySQL DB without sanitizing, the answer is a huge yes. This is something you need to decide for yourself if you aren't going to show code.
The solution you've got in the linked question is pretty safe.
Every possible action is hardcoded in your script.
Nothing to worry about.
Though asking for the "web form like this" you'd better to provide a web form. Not the link to the question that contains a code that can be presumed as this form's handler.
I'm trying to speed up response times in my ajax web application by doing the following:
Say the user requests a page whose contents don't change (e.g a web form). When the user makes a different request, I 'cache' the form by putting it in a hidden div. Before displaying the new information. So the form is basically still loaded in the browser but not visible to the user. If the user requests the same form again, it gets loaded from the hidden div. That's notably faster than doing a round-trip to the server for the form.
I do realise doing so with lots of data will probably degrade performance as the browser gets to keep a lot in memory. But I will place a limit on how much gets "cached" this way.
Now, I came up with this on my own which is why I'd like to know if there is a better/established way of doing this. It works as expected but I don't know what the possible drawbacks are (security-related perhaps?).
I would appreciate any suggestions.
Many thanks.
I've done this before. It can be a useful technique. Just make sure the data is accurate and that you support JS disabled user agents.
EDIT: And that there is no better solution.
Storing the HTML code for your form in a JS variable is probably more efficient than having a hidden div with the interpretation of this HTML code (form + form fields + various markup).
If your form code is generated at the same time as the page, simply print it in a JS variable :
<script language="javascript">
var myFormCode = '<? echo $myFormCode; ?>';
</script>
(That's if you use PHP...other languages shouldn't be far from that)
If your form code is generated later, you can send it as text via JSON :
<?php
echo json_encode($myFormCode);
?>
...and then build your form when needed, with something like that on the client side :
<script language="javascript">
myRealFormDiv.innerHTML = eval(myJSONEncodedTextIGotViaAJAX);
</script>
JS code is obviously not exactly what you need to type in, but you probably see my point.
This should work and is the best solution I can think of. Whether there are any security implications really depends on your forms and how they work - nobody will be able to diagnose this without actual code.
What about use APC or Memcached ?
They'll allow you to keep the html markup clean, with not 'hidden tricks' that could potentially create problems (user dont have css enabled? use IE6? what about accessibility?)
Depends on your needs, but in general way the page must contain just what it must containt, nothing else.
Another way of doing this is to set the "Expires" or "Cache-Control" HTTP headers for the form.
If you set an "Expires" header 1 hour in the future for url http://example.com/form.html, then the next time within an hour that the user navigates to that form the HTML will be loaded without touching the server.
If you properly version your images/CSS/JS and give them far-future "Expires" headers as well, then there will be no server roundtrip, plus you'll help the performance the rest of your pages.