3

I'm not sure if this question is within the scope of security.stackexchange or it would be more suitable on stackoverflow. Let me know if needed.

I'm wetting my feet in PHP, and I've put together a very simple program that (using JavaScript) receives as user input a .txt file, sanitizes it to remove all punctuation, then sends the string (via ajax post) to a php script that does some very simple calculations (e.g. the length of the string, how many times a certain substring appears, etc), then returns the results to the JS script for display on the web page.

My question is:
Is there anything risky about this process if we assumed a malicious user? Is there anything they could upload and send to the php script that would compromise the server? My instinct is to say no, since the PHP script is extremely simple and only performs string calculations (not to mention that all punctuation is removed from the input file), but since I'm really inexperienced with PHP, I thought to ask and make sure before I share it with anyone.

If any further information is required, let me know.

3
  • Without seeing the code it is impossible to say for sure, but from your description, it doesn't seem like there is any vulnerability here. – nobody Feb 10 at 13:44
  • 1
    Don't forget that you cannot safely perform sanitization on the frontend. If you are removing punctuation to stop PHP from interpreting it in valid code, then you are vulnerable. If you're just doing it to get the txt file into a standard format, then why bother doing it on the frontend instead of the backend? How does your PHP code respond if it gets a string with punctuation anyway? – matoro Feb 10 at 17:08
  • Indeed, I did it on the frontend because I was unable to properly pass the string to PHP. I discovered that if the string contained punctuation, it kept throwing syntax error. I'm using $.post("file.php", { variable: string }, function (data) {console.log(data)} to send the string, and on file.php I receive it with $string= $_POST['variable'];. Could you elaborate on how this could be interpreted as valid code? I mean, if file.php, as I said, only performs simple string operations, is it still possible that code be executed? – TasosPaterakis Feb 10 at 18:41
3

Anything you do on the client-side can be ignored by an attacker. They don't even need to visit your web page in order to send requests to the PHP script - they can send those requests directly with whatever inputs they like.

If you're just using functions like strlen, intval, etc. for parsing the string and converting it into numbers for calculations, there's nothing there for an attacker to abuse in order to compromise the server. There are risky (and downright dangerous) functions in PHP, like eval, exec, and system, but if you're not using them then they're not a problem.

If the script is as simple as you described, the worst an attacker could really do is send some data that can't be converted to a number, which would cause the page to throw an error. This doesn't do anything to your server or any other user of the site - it's just that request that fails. If your server is configured to display errors, it might tell them the path to the PHP file on your server, which is a minor information disclosure.

I suspect from your comments about punctuation that you're thinking about things like SQL injection. This is only a problem when you're making queries to a database, which you aren't doing here. When you do get around to learning about database queries, ensure that you're using parameterised queries/statements with MySQLi or PDO, instead of string concatenation. There are quite a few questions on here on this topic that you can refer to once you get to that point.

2
  • This is a clear and elaborate answer, I appreciate it. One last thing: I use <?php session_start(); $var1 = 42354; //random number $_SESSION['var2'] = $var1 ?> on the originating page ("index.php", basically an html page) and session_start(); $var1 = $_SESSION['var2']; if ($var1 !== 42354) { die('Direct access not permitted'); } on the receiving page ("file.php"). Am I right to assume this prevents sending requests to the PHP script directly? – TasosPaterakis Feb 11 at 5:18
  • @TasosPaterakis No, that doesn't prevent anything. An attacker can trivially send a session cookie as part of a custom HTTP request. Here's an example with cURL. – Polynomial Feb 11 at 11:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.