0

I'm working on sending a couple of values to a PHP script and it is using the following;

echo '<td><a href="webpage1.php?var1=' . $var . '</a></td>';

This is fine for data which isn't important. However this allows users to add data in the URL and potentially view/obtain secure data.

Here's my idea on how to resolve it (Without Posting the data)

  • Create a random number or phrase

  • Pass this value with the GET and with a session variable

  • Compare that the two match before doing anything important (GET & Session)

This there any other ways of doing this or is Posting the data from a form a better approach?

dan983
  • 454
  • 2
  • 5
  • 19
  • 3
    A user can manipulate the data via POST, too. One is *not* any more secure than the other. With a program like https://github.com/wiztools/rest-client I can send whatever requests I want to your server. – gen_Eric Jan 07 '15 at 15:04
  • 3
    If the GET value can be stored in the session then why not just save the value there and do away with sending it to the client? – Jim Jan 07 '15 at 15:05
  • 1
    posting is better - you shouldn't modify on a GET. imagine a delete on a GET - if a search engine crawls the links - it could empty your data. – Daniel A. White Jan 07 '15 at 15:07
  • @Daniel A. White, good point however i would expect any kind of delete/modify functionality to be behind session based login code. – MadDokMike Jan 07 '15 at 15:12
  • simple: allow the user to specify whatever they want. `webpage1.php` should simply validate that input and toss away/ignore anything that shouldn't be there. – Marc B Jan 07 '15 at 15:15

3 Answers3

2

If the data needs to been kept secure from the user then it must never be sent to the browser.

Keep it on the server and give the browser an ID to reference it with instead. Apply whatever Authn/Authz you need on top of that.

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
0

Another way to secure it would be the fact you should know what you expect $var to be, so if user has supplied something in the url that does not conform to your rules then you can reject it. It really depends how sensitive $var really is.

MadDokMike
  • 182
  • 5
0

POST is no more secure than GET over the HTTP protocol. Security-wise, they are inherently the same. Pass secure data encrypted and over SSL.

As far as security [goes], they are inherently the same. While it is true that POST doesn't expose information via the URL, it exposes just as much information as a GET in the actual network communication between the client and server. If you need to pass information that is sensitive, your first line of defense would be to pass it using Secure HTTP. Source

If you are passing $var over the wire, and you are worried that it could be modified to access another user's data, for example, then you should be performing checking, server-side, whether the user in the session has access to that $var variable. Usually this is an id variable you associate with an element on the client-side which is then passed up via AJAX or normal Http Request.

A modification of this variable would return a 404 Not Found if the var is actually an id pointing to something server-side.

Imagine: /resources/24 as your URL. 24 is a unique id. Your first point of call would be to make sure that 24 is allowed to be accessed by the currently logged in user (your data model would normally be used here - your resources table would have a one to many association with a user and you would use that as your basis for authentication).

In effect, POST is no more secure than GET. If you need to pass sensitive information, use https:// and encrypt the sensitive data. Otherwise, do what feels right in the context of the application and authorize against the currently logged-in user server-side.

Community
  • 1
  • 1
Jimbo
  • 25,790
  • 15
  • 86
  • 131