Inquiry on JS Protection

[diamondf]

So, perhaps I'm a bit paranoid after having run through some of the challenges on this site, but after doing the JS missions, I contemplated a way to break my web forms in a way that would, well, cause a lot of problems. I've spent a few hours checking into JS a bit more and trying to root out a way to complete it. I have tried to create the exploit (so as to find a way to secure against it), and un/fortunately(?) not had any success with it.

So, lets say we have a simple form:

Code: Select all

if($_SESSION['logged_in'] == true) {
echo "
<input type='text' name='point_type' value='" . cleanString($_POST['point_type']) . "' /><br />
<input type='text' name='increment_points' value='"  ($_POST['increment_points'] + 0). . "' /><br />
<input type='submit' name='submit' value='Submit' />";
}


For the sake of argument, lets say that the user has a reason to submit this form once in a while, but not too frequently. If another person were to come along and activate it a lot, that would be a major problem.

Now, the form only loads when you're logged in. But if a user is logged into that site and gets hit with a particular JS script, what stops the JS script routing back to that site, adding the right content, then submitting the form? For example, something like:

Code: Select all

javascript: window.location("http://thesiteabove.com/yourform.php"); document.getElementsByTagName('input')[0].value='number_of_rocks'; document.getElementsByTagName('input')[1].value='99999'; document.forms[0].submit();


I've managed to use that code successfully to redirect the user (me) to the form in a logged-in state, but I can't get the form to submit. What I want to know is whether that's because I'm not using the right combination of JS, or because there's internal security on apache (local webserver), nginx (public webserver), php, or something else like firefox that's trying to restrict it (but ultimately the use of a different web program could in fact submit the form).

Obviously, webcrawlers can go around posting on forms. That much doesn't really concern me, because in order for this to be a risk, the user themselves have to be enticed to activating the script. Can someone help answer this?

[Assassian360]

Your question is not entirely clear in wording, but it looks to be a question of "how do I stop someone submitting information via a form that I don't want them to?".

There are 3 levels of validation that you can do. The first two are optional, and the 3rd should be done in most cases.
1) Element level validation - this would be javascript that triggers based on an event like the user is typing in a particular textbox or they have just left the textbox etc. On the even you would then validate the content of the box. This will not stop someone as it can be got around through disabling javascript.

2) Form level validation - when the user tries to submit the form each element of the form can be validated and the form then only submitted if all the content is valid. This would also be done with a javascript event. It can also be avoided quite easily.

3) Server side validation - when the server receives any data from a user it should not be assumed to be valid, especially because the first two forms of validation can so easily be stopped or just not used at all. So whatever the data is should be checked and validated.

Validation can be as simple as checking whether the content is a number or a date etc. It could also include range checking. You said about the user writing 99999, you could limit the range of allowed values to a particular upper and lower bound. This would protect from potential problems from users submitting suspicious values.

Does this answer your question?
I can go into more detail if you want.

[diamondf]

Hi Assassin

Thanks for taking the time to help me out with this. Sorry if my problem wasn't entirely clear. Let me go a little more in depth to try to clarify the points with some additional / revised coding examples, and I'll respond to your answers as well.

The code involved is over two pages; one that represents the user sending a request, and the other that represents the user receiving the request, and updating the appropriate information. Thus, the information can actually be inserted into the form from any page using $_GET, leaving that page theoretically insecure to even a simple link outside of the site, even if there were no Javascript intervention. To prevent that, I use an sha1() hash that is generated within the site, and appended to the list, preventing forgeries from outside generation.

However, the user can edit their own page (like a personal blog, myspace, whatever), and they are allowed to use Javascript (I know many of you are probably wondering wtf is wrong with me upon saying that). So on their page, they could create a script that sends this information, but could also (presumably) force-submit that information once they've redirected you back to that page with the appropriate scripting.

For Server Side validation, I have the authenticity of information validated by a hash variable that is sent by another page that is generating the information for it, which is received through $_GET.

Code: Select all

$point_type = "number_of_rocks";
$increment_number = 10;
$from_user = "Joe";
$user_pass = "xyz";
// Assume that the three variables above can be edited.

$hash = sha1($point_type . $increment_number . $from_user . $user_pass);

echo "
<div><a href='next_page.php?pType=" . $point_type . "&user=" . $from_user . "&inc=" . $increment_number . "&hash=" . $hash . "'>Link</a></div>";


Now, you click on the link from the other page, and receive the information on the second page.

Code: Select all

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

  $checkPoints = array('number_of_rocks' => 1, 'number_of_plates' => 1, 'number_of_pencils' => 1);

  if(isset($checkPoints[$_POST['point_type']])) {
   
    if(($_POST['increment_points'] + 0) < 500)
    {
        // Check User's Password
        $query = "SELECT pass FROM user WHERE username='" . protectSQL($_POST['user']) . "' LIMIT 1";
        $res = mysql_query($query);
        if(mysql_num_rows($res) > 0) { $fetch_pass = mysql_fetch_assoc($res); }

        // Test Hash
        if($_GET['hash'] == sha1($_POST['point_type'] . $_POST['increment_points'] . $_POST['user'] . $fetch_pass))
        {
           // Submit SQL
           $query = "INSERT INTO `table` ( `point_type`, `inc` ) VALUES ( '" . protectSQL($_POST['point_type']) . "', '" . ($_POST['increment_points'] + 0) . "'";
           mysql_query($query);
           echo "You submitted the entry.";
        }
    }

  }
}

if($_SESSION['logged_in'] == true) {
echo "
<form action='thispage.php?user=" . cleanString($_GET['user']) . "&hash=" . cleanString($_GET['hash']) . ">
<input type='text' name='point_type' value='" . cleanString($_GET['point_type']) . "' /><br />
<input type='text' name='increment_points' value='"  ($_GET['inc'] + 0). . "' /><br />
<input type='submit' name='submit' value='Submit' />
</form>";
}


My question is, what happens when somebody adds a script to that first page that runs this:

Code: Select all

// Assume the hash has all the correct variables
$hash = sha1($point_type . $increment_number . $from_user . $user_pass);

<body onLoad='javascript: var getDiv=document.getElementsByTagName('div')[0].innerHTML; var hash = a.substring(a.indexOf("&hash=" + 6, a.indexOf("Link") - 1); window.location("http://thesiteabove.com/yourform.php?hash=" + hash + "&user=Joe"); document.getElementsByTagName('input')[0].value='number_of_rocks'; document.getElementsByTagName('input')[1].value='450'; document.forms[0].submit();

echo "
<div><a href='next_page.php?pType=" . $point_type . "&user=" . $from_user . "&inc=" . $increment_number . "&hash=" . $hash . "'>Link</a></div>";


The point of the script is to get the information you need on the first page, redirect the user to their own page (where they will be logged into the site, bypassing the Server Side preventions), input the desired information into the form, and then submit the form using the Javascript submit() function. (( As opposed to the preferable alternative, where the user is redirected to his page, but is then given the option of submitting the form or not, after considering the values. ))

Does this make sense?

My original question then, is what is stopping anyone from doing this. I have managed to redirect the page to form, bypassing the login issue, but the submit() function doesn't work after redirection (thus far). I'm not sure why, and I'm looking for a reason so that I can understand the security measures behind it.

[sanddbox]

Your issue is pretty simple: you're checking if their logged in when showing the form, instead of checking if they're logged in both when you show the form and when they submit the data. Also, make sure to add a CSRF token to the form.

[diamondf]

Hey Sandbox, thanks for your reply. It directed me to exactly what I was looking for. I did some research, and the wikipedia page that I found phrased "Attackers can write JavaScript or ActionScript that invisibly submits a POST form to the target domain" which is precisely the question I had. As it explains, I was correct in most of my assumptions, and that it needs to be secured more appropriately. I still do have some questions on this topic, however, for the sake of clarification.

First of all, for some reason it never occurred to me to think of what was interpreting the JS. Obviously if the person is using a secure browser, the browser could recognize the JS and say "Uh, no." Using FF3, I'm assuming that it was the reason I wasn't able to actually produce the effect so far. Having taken that into consideration, that's a good thing, as it means that a lot of people will already be protected against the specific issue of the javascript submit() function after a redirect. (( This does, of course, assume that I designed the code to JS exploit correctly. ))

So now I have to consider the possibility of a less secure browser, such as Internet Explorer; particularly older versions. If their browser isn't adequately protected, I would still need to account for a better system, such as the CSRF.

So let's say the person trying to exploit this is savvy, and knows how to BS the referrer header.

[ Example taken from mustap.com ]

Code: Select all

<?php

$host = "www.mysite.com";
$file = "formprocess.php";

// construct a header for our request
$hdrs = array( 'http' => array(
    'method' => "POST",

    'header'=> "accept-language: en\r\n" .
        "Host: $host\r\n" .
        "Referer: http://$host\r\n" .  // Setting the http-referer
        "Content-Type: application/x-www-form-urlencoded\r\n" .
        "Content-Length: 33\r\n\r\n" .
        "username=mustap&comment=NOCOMMENT\r\n"
    )
);

// get the requested page from the server
// with our header as a request-header

$context = stream_context_create($hdrs);
$fp = fopen("http://" . $host . "/" . $file, 'r', false, $context);
fpassthru($fp);
fclose($fp);
?>


They set up a site, and redirect the victim to THEIR site, then load MY site (which the user happens to be logged into). Now they use the javascript to submit the form, but the protection against the header value is insecure. The possible exception is a victim's browser, because their system has to be bugged in order to spoof through that. Which means I may just be safe if I do a standard referrer check from the outside. Am I correct in that assumption, or would the code example above, mixed with a malicious script still cause a security exploit?

In other words, does this work:

Code: Select all

if ( eregi ( "www.mysite.com", $_SERVER['HTTP_REFERER'] ) )
{
    // Allow Access
}


The assumption being that somebody could, through their browser, post a form through an automated script that didn't come from the site, but they could NOT entice a victim's browser to do the same. Thus preventing the abuse of the victim's page being compromised.

[tremor77]

Recode the entire thing in PHP to start. Javascript is parsed by the browser/client - and will always be vulnerable in some manner. Atleast with PHP you put the work on the server... and your code isn't visible. Additionally when people turn on/off javascript it breaks your scripts. Javascript can so some pretty nifty stuff, couple with AJAX and stylesheets... I find it to be terrific for create aesthetic and visual enhancements on a website.

But regarding security and data transmission, it should be avoided like the plague. Your skills appear to be sufficient that you could rework that into PHP in no time.

[diamondf]

Well, I'm actually not using any Javascript on my page, it's all PHP. I just wrote the Javascript in an attempt to hack it. I'm trying to find out how to prevent this particular JS issue, basically.