1

Is it safe to use $_POST for button action ?

for ex.

<button name="submit">Table A</button>

php (what my code here does is, if i click the button(Table A) the table A will appear then, in default is not viewable.)

    if(isset($_POST['submit'])) {

        <table>
          code....
        </table>    

}

FOR MY QUESTION: is it safe ? to the attacker ? like xss, sql injection, or something ? I want an advice, to have more safer website. (or atleast safer from attackers)

phew
  • 147
  • 2
  • 10
  • need to use type as submit. – Murad Hasan May 18 '16 at 09:15
  • you have always to do escape of the every input you are getting from customer or request. It's not safe. – Farside May 18 '16 at 09:15
  • Possible duplicate of [Understanding input escaping in PHP](http://stackoverflow.com/questions/457014/understanding-input-escaping-in-php) – Farside May 18 '16 at 09:16
  • so will I do this kind of code?, if(escape(isset($_POST['submit']))) {} (Note: my escape here is from a class) @Farside – phew May 18 '16 at 09:35
  • This question is too broad, you need to define what you mean by "safe" – Martin May 18 '16 at 09:54
  • @martin, sorry, what my point is, if I do the code up there and apply to my website, will it be safe(good against) to the attackers ? or is it easy to attack? sorry martin – phew May 18 '16 at 09:57
  • My point is safe is a relative term, as in how windy is it today, and how safe is ths website are completely relative terms. Your website code above suffers from CSRF. So I would deem it Unsafe. Please see my answer. – Martin May 18 '16 at 10:02
  • yeah, thanks, I'm trying now a code with token generating function that will only confirm if the token generate is true. Is it okay to fight against CSRF? i read at owasp.org using token is recommended. – phew May 18 '16 at 10:13
  • Yes token generation is correct, your token needs to be long enough to be hard to fake (so typically like a password), and needs to be passed to the recieving page in a non-browser route, such as via a database or a SESSION, or a file on the server. – Martin May 18 '16 at 11:12

4 Answers4

2

It is safe provided you don't echo the output or use it unescaped within a SQL statement. Also your code should really be...

if(isset($_POST['submit'])) {
...
}

to avoid errors if it isn't set

Barry
  • 3,303
  • 7
  • 23
  • 42
  • sorry, i forgot to type the isset here, but on the table, I will echo something users inputted before (eg. username etc.). Is it stiill okay? (and it already escaped) – phew May 18 '16 at 09:39
  • all data that is either displayed or used in SQL should be sanatised in case of cross site scripting (XSS) or sql injection. – Barry May 18 '16 at 10:08
0

Short answer

NO

POST variables are not 'safe' on their own.

Long Answer:

There are many issues around authenticating POSTed variables on your PHP script. The most well known is Cross Site Request Forgeries whereby the value is sent to your page but you have no idea where the value came from, or who sent it.

To counter this you need to set up single use unique keys to send and receive, typically using PHP SESSIONS or similar concepts that can not be touched by the end user.

The second issue is that you should never ever ever trust the contents of a POSTed variable. you need to fully escape the variable as well as ensuring that the variable is given absolutely minimum access to your code, so if it is a compromised value, it is hopefully cleaned and/or it can not harm your script.

Your Code:

Looking at your question in detail you suffer from CSRF (point 1, above) in that your PHP code has no idea if the submitted button came from the page your button exists on and therefore the PHP has no idea if the browser should see the contents of "Table A". (If everyone can see it, why hide it in the first place?)

There is also the factor your code could be used by a nefarious party to send many, many POSTed submits to the script, over a short space of time (100,000 over 2 seconds) causing a DOS attack, again due to there being no validation of where the POST came from and its implied authenticity.

Further points: You need to clarify what you deem as "safe", it is a very relative term.

Community
  • 1
  • 1
Martin
  • 22,212
  • 11
  • 70
  • 132
  • the reason I hide it is because it is view per table, ex. if they click table a button, table a will appear, and if table b button then table b will, so on. And if I add a code like this if(!escape(isset($_POST['submit'])) { //code error } is it okay ? – phew May 18 '16 at 10:19
  • to be honest then that doesn't need forms or POSTed info at all, simply use javascript to show/hide CSS elements. @phew – Martin May 18 '16 at 10:30
  • @phew no, your escaped string will still need protection from being suseptible to CSRF. – Martin May 18 '16 at 10:31
  • [This question and anwsers](http://stackoverflow.com/questions/17638990/jquery-show-and-hide-div-on-mouse-click-animate) my be of interest to you, to do it using Javascript method sidestepping forms entirely. @phew – Martin May 18 '16 at 11:10
0

Developer has always to sanitize and to validate the input he's getting from the request.

Depending on the purposes - you need either to enforce the sanitation or to make less cleaning (for example for DB you need to clean it up/escape additionally, for HTML output to make XSS protection, etc.)

You may read up on:

  • How to sanitize the input (POST/GET variables, referral, cookies, user agent, and other headers)
  • Cross-Site Request Forgery (CSRF) prevention;
  • additionally you may want to use Captcha or other protection from automatic submits, etc.

For your specific purposes, in the question itself - you are not using the value of $_POST['submit'] in any way, except checking of presence, so no additional validation is needed, it's fine like that.

Community
  • 1
  • 1
Farside
  • 9,923
  • 4
  • 47
  • 60
  • so in the '$_POST' where I will place the escape function ? am I right ? – phew May 18 '16 at 10:22
  • From your code, it's not really clear, how you are going to use the rest of variables from POST... But the generic answer is - you have *always* to sanitize every variable from the input, which you are going to use in further actions (DB storage, calculations, HTML output, etc). For example for the case `isset($_POST['submit'])` it's enough, you may also use simple `(bool)` cast to get the TRUE/FALSE result, it's another way of doing it. Type casts, escaping, additional processing and clean-up, it's all about sanitizing the input. Please, find out more info by the links I provided – Farside May 18 '16 at 10:27
  • thank you very much, now I do CSRF token-"like" coding, and I use it to validate the button action, btw, may I ask additional question to you ? though it is not related to my posted question. – phew May 18 '16 at 10:31
  • @phew, up-vote/accept if you found the answer anyhow useful. Shot your additional questions, sure. Or it would be better to discuss in a chat, but I'm not sure how to create it, without the long conversation here. – Farside May 18 '16 at 10:38
  • i try to code like this action in my a href: viewUser.php?viewUser=data()->hash;?> is this okay ? the reason I do this is because, the hash itself is my basis of who the user is(who owns that hash) then it go to the said page and it will echo the right thing. is it okay? is it vulnerable? – phew May 18 '16 at 10:45
  • 1
    @phew, the general answer is - it's ok, with two assumptions: 1. you have already sanitized the data from the object, on previous stages, when the data object was created/fetched. 2. you'll do [`urlencode`](http://php.net/manual/en/function.urlencode.php) of the `query string` when you make the url. – Farside May 18 '16 at 11:02
  • i do not see the difference when I add urlencode mister @farside – phew May 18 '16 at 12:20
  • @phew, but do you even understand the difference and why `urlencode` is normally used for? Read [what `URL-encoded string` is](http://www.w3schools.com/tags/ref_urlencode.asp), and why this escaping is needed for! Asking every question, which can be found by simple look-up in the PHP manual is not *comme il faut*. – Farside May 18 '16 at 12:34
  • i am really sorry @farside – phew May 18 '16 at 12:53
  • my urlencoded hash does not add some %2F or something ? is it natural ? – phew May 18 '16 at 13:04
  • @phew, you might be kidding me? :) I provided the links, references, docs, etc. Are you reading them at all? Aren't they explicit? `urlencode` - will transform to `%2F` and other URL-encoded chars, only in case of need, when something special it will get, which can't be directly be pased in the URL. Up-vote at least my answer or accept it, to alleviate my suffering, hehe, it would be at least some reward :-D – Farside May 18 '16 at 13:45
-1

You can use the button with POST. But make sure, you have validated the referrer URL of the action. Because someone may try to copy your form and submit in loop. This will down your site.

So you should check the referrer URL matches with your site URL.

Also always use form token to validate the form (Like captcha)

Karthikeyani Srijish
  • 470
  • 3
  • 7
  • can you give me some example of this ? – phew May 18 '16 at 09:38
  • When you submit the form, get $_SERVER["HTTP_REFERER"] and compare with your base URL. If both matches then allow the action. Else terminate it. – Karthikeyani Srijish May 18 '16 at 09:47
  • it's bad idea to validate the referral, as this info comes from the request as well, and could be easily faked up. [**CSRF** token](http://stackoverflow.com/questions/6287903/how-to-properly-add-csrf-token-using-php) protection is the thing I'd use instead. I'm down-voting your answer. – Farside May 18 '16 at 09:48
  • @Farside I can understand the referrer detail will also come in request and can be changed using CURL. But could you please explain how to validate a form that is accessed from different website? Except captcha or form token. – Karthikeyani Srijish May 18 '16 at 09:52
  • All the input data your are getting from the request could be easily faked, including REFERRAL, cookies, user agent, and other headers. It's not reliable and has to be validated/sanitized as well. The common practice to protect the form submit and ensure it's from where it comes is to use [**CSRF** token](http://stackoverflow.com/questions/6287903/how-to-properly-add-csrf-token-using-php) protection. And in this case - you still need to **sanitize the input**, always. – Farside May 18 '16 at 10:03
  • @Karthikeyani, and don't mess up the things, all in one :) Captcha serves totally different purposes. Input sanitizing - is different purpose. Cross-Site Request Forgery (CSRF) prevention is another story, separately from those... – Farside May 18 '16 at 10:08