3

I am currently studying for a computer security exam and I am stuck on the following question from a past exam paper

Question

1c  <form action=”message.php” method=”get”>
2c  <p>Message: <input type=”text” name=”message” /></p>
3c  <p>Username: <input type=”text” name=”user” /></p>
4c  <p>Password: <input type=”text” name=”pass” /></p>
5c  <p><input type=”submit” /></p>

1s  <?php
2s  $user = $ ̇REQUEST[”user”];
3s  $pass = $ ̇REQUEST[”pass”];
4s  $message = $ ̇REQUEST[”message”];
5s  $result = mysqli_multi_query($con,”UPDATE messages SET
6s     message=”.$message.” WHERE user=”.$user.””);
7s  $row = mysqli_fetch_array($result);
8s  if (!empty($row)) {
9s     echo ”Your message: ”.$message.” has been added”;
10s   }
11s  ?>

I know I should look for things like SQL injection, XSS, Cross-site request forgery, etc ...

My attempt:

  • $user could be used for SQL injection as it is not sanitized
  • password is not verified anywhere (?)
  • echo $message also looks like vulnerable part (input not sanitized again) but not sure what would be the exploit (some sort of XSS?)

I would really appreciate if someone could highlight the vulnerable parts of the code or even explain why they are vulnerable.

  • are there four? – Vipul Nair Apr 9 at 16:42
  • @vipulnair At least six, from a quick look! – Matthew Apr 9 at 16:47
  • 1
    @ischelp 1.sql injection 2.csrf 3stored xss by changing other user messages 4.reflected xss using csrf. – Vipul Nair Apr 9 at 17:09
  • 1
    Between you you've got 5 - I'd add password being entered in text input rather than password input (shoulder surfing risk), and using a multiple query function when only a single query is expected (not sufficient to prevent sqli on its own, but would make abusing this one harder, since it's an update). – Matthew Apr 9 at 19:18
  • 1
    By the way, it's not about the answers. It's about understanding the code what an attacker can do to it. If this is not clear, I suggest to study a bit more rather than asking for answers. – Jeroen Apr 9 at 22:34
2

Vulnerabilities 1 & 2:

5s  $result = mysqli_multi_query($con,”UPDATE messages SET
6s     message=”.$message.” WHERE user=”.$user.””);

These are SQL injection vulnerabilities. The program invokes a SQL query built using input coming from an untrusted source. As you pointed out $USER is vulnerable but $message is also.

Vulnerability 3:

8s  if (!empty($row)) {
9s     echo ”Your message: ”.$message.” has been added”;
10s   }

This is an XSS vulnerability. Although it is hard to classify specifically the type given the little amount of source code, because the data is being stored in a DB (thus making it persistent); however the example code does not show other areas it is output, so we can only state that it is reflected at this point.

Potential Vulnerability 4:

3s  $pass = $ ̇REQUEST[”pass”];

Computer programs depend largely on context, so while it appears that the author of this program wanted to authenticate, this may not be the case. If the author did want to authenticate, then $pass is not checked anywhere. Regardless of if this is a vulnerability, this is unused code. It is bad practice to leave unused code in a production program.

Potential Vulnerability 5:
1c <form action=”message.php” method=”get”>

This is potentially a CSRF vulnerability. Once again this is dependent on the programmers intent to have validation. If they did then the form post must contain a user-specific secret in order to prevent an attacker from making unauthorized requests.

Potential Vulnerabilities 6 & 7:

5s  $result = mysqli_multi_query($con,”UPDATE messages SET
6s     message=”.$message.” WHERE user=”.$user.””);

$message and $USER are potentially stored XSS vulnerabilities, although the sample code does not show these variables getting retrieved, it would be fairly safe to assume these may be displayed in another part of the program.

Potential Vulnerability 8:
4c <p>Password: <input type=”text” name=”pass” /></p>

This is potentially a shoulder surf vulnerability. This input should be obfuscated. Once again this depends on the programmers intent to actually validate, and the actual meaning of the pass input field. We can assume that this is a password, but unless we get confirmation from the programmer, it is just that, an assumption.

Potential Vulnerability 9:

1c  <form action=”message.php” method=”get”>
2c  <p>Message: <input type=”text” name=”message” /></p>
3c  <p>Username: <input type=”text” name=”user” /></p>
4c  <p>Password: <input type=”text” name=”pass” /></p>
5c  <p><input type=”submit” /></p>

This is potentially a shoulder surf vulnerability. This will result in a GET request displaying the password on the URL, which could result in a shoulder surf attack. Once again this is dependent on the programmer' intent.

  • Besides the fact that the password is shown in the URL, it will also be stored in proxy server and web server logs. – Jeroen Apr 9 at 22:36

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.