1

I have a simple form that sends form data to update.php which then inserts the data into a table in a MySQL database.

$.ajax({
  url: '/actions/update.php',
  type: 'post',
  data: {
    name: 'name-data',
    description:'description-data'
  },
  success: function( data, textStatus, jQxhr ){
    console.log(data);
  },
  error: function( jqXhr, textStatus, errorThrown ){
    console.log(errorThrown);
  }
});

The form works and the data is added into the database perfectly. The problem is that in theory, if the user knows the url of where the data is being posted to (which they may if the look at the source code) then they can visit that URL and add records bypassing the form. e.g. visiting /actions/update.php will add a blank record to the database.

Is there away to block users to that file/directory while still allowing data to be posted to it?

cnrhgn
  • 703
  • 4
  • 18
  • Have you tried `header` in `update.php`? – Zain Farooq Sep 08 '18 at 18:20
  • If your's is a Codeigniter project, then adding CSRF to your forms may help from unauthorized random posts. You can do it without Codeigniter too but that will require a bit more work. – Venkat D Sep 08 '18 at 18:24
  • Try `header('Location: somepage.php/');` at the top of `update.php` – Zain Farooq Sep 08 '18 at 18:25
  • You can try hiding the url by importing it from another file or use a key. I would say use a key – Krishanu Sep 08 '18 at 18:26
  • @ZainFarooq wouldn't that make it impossible to access the data – Krishanu Sep 08 '18 at 18:27
  • @Krishanu I don't know actually. I want him to give it a try and give results – Zain Farooq Sep 08 '18 at 18:30
  • https://stackoverflow.com/questions/2579254/does-serverhttp-x-requested-with-exist-in-php-or-not – Zain Farooq Sep 08 '18 at 18:32
  • 1. Is update.php password protected? IMO, it should. 2. Adding ACL will solve nearly all your problems of unwanted/unauthorized entries to your database at the user level at least. 3. Adding CSRF protection will make it secure enough to reject all "script" kiddie type of attacks unless you are being targeted by an accomplished hacker. – Venkat D Sep 08 '18 at 18:37
  • There are some useful tips here. https://stackoverflow.com/questions/6287903/how-to-properly-add-csrf-token-using-php Bet you will find plenty more to secure your plain vanilla PHP user submitted forms. – Venkat D Sep 08 '18 at 18:42

3 Answers3

3

Is there away to block users to that file/directory while still allowing data to be posted to it?

This is the wrong way of thinking about the problem.

If the client-side JavaScript can make that request, then a user can make any request whatsoever to the same PHP file.

Instead, in your PHP you need to validate that the parameters being passed fit your definition of acceptable.

For example, you might need to check that the name and description parameters are under a certain character length, or that the current logged in user has permission to update the relevant record.

Think carefully about what is and is not acceptable. Once you've added these checks, it won't matter if the user "visit[s] that URL and add records bypassing the form".

thirtydot
  • 224,678
  • 48
  • 389
  • 349
1

I think the possible solution is that you can block users if your variables name and description are not set with post request

if(isset($_POST['name']) && isset($_POST['description']))
  {
    //do your task
  }
  else
  {
    header('Location:otherpage.php')// redirecting it to other page if user visits it directly
  }
Zain Farooq
  • 2,956
  • 3
  • 20
  • 42
0

If users can visit the URL, it means that GET request is allowed. You need to only accept POST request.

Nathanael Demacon
  • 1,169
  • 7
  • 19
  • you can still acces the data through a third party application like postman – Krishanu Sep 08 '18 at 18:25
  • Users can always create a random HTML form and still post to his controller unless there is some server side validation of "request source". So adding if($_SERVER['REQUEST_METHOD'] === 'POST') { //allow data to be inserted} else { //reject request } achieves only limited protection. – Venkat D Sep 08 '18 at 18:27