0

I send the email and password unencrypted via the POST method over HTTP not HTTPS.

Is it possible for someone to see the raw post data?

I imagine raw post data looks like this: email='example@aaa.com'&password='qazwsx'

I know that I should encrypt passwords but that's just an example I made up.

In reality I pass a lot more sensitive information.

EDIT:

I currently have a php script called register.php which does exactly what the name implies.

Anyone who is smart enough to guess that I'm using two variables named "email" and "password" could achieve the registration of a new user just by sending some POST data. How can I prevent this exploit? Obviously, it has nothing to do with SSL, it's a second concern I have.

I don't want a 17 years old "hacker" to generate 18,838,929 new accounts in 3 days.

Nick Keroulis
  • 133
  • 1
  • 6
  • 4
    Yes, it is vulnerable for man in the middle attack – user4035 May 16 '15 at 19:57
  • The short answer is yes. There are security issues when you send data over http protocol. You better check that: http://stackoverflow.com/questions/2003262/how-to-send-password-securely-via-http-using-javascript-in-absence-of-https?lq=1 – Greg Kelesidis May 16 '15 at 20:22
  • Then, why would he bother decrypt it if it's encrypted? Why not write a five minute HTML script to send the data he saw and achieve a login? – Nick Keroulis May 16 '15 at 20:22
  • 1
    To avoid automization use captcha. It deal with spam, only human can execute \ make call of this action, all others will be ignored. – user1954544 May 16 '15 at 20:41
  • Also you can use 'one email per account' and others features to make creation of account 'not so quick'. Base thing that you cannot avoid manual registration of 100500 account. – user1954544 May 16 '15 at 20:44
  • But, I want it to be fast. – Nick Keroulis May 16 '15 at 21:07
  • Yeah, you can't avoid it, and I would not call it an exploit as anyone could write a small automation script. You're HTML/ whatever form is not even required. Someone could save your page to your computer, take the form fields and start sending random data from those fields. You can take care of that by checking referring URL. Still, the form on your site would be vulnerable. You can check IP's ( a start, ) limit login attempts ( a good idea for what you are wanting. ) Or you can use a CAPTCHA which is very difficult for bots to crack. – Evan Carslake May 16 '15 at 21:38

2 Answers2

2

POST data is sent unencrypted in the request body. It is as safe as passing it using GET, though less visual. If your users are connected for instance via a public/unsecure (WiFi) network, there is always a chance that someone behind the network intercepts the traffic and all HTTP data.

Considering you pass around sensitive data, the safest solution is to use HTTP over SSL (HTTPS). This will take care of encryption for you. You could also do some sort of inhouse client-side encryption and then send the data, but HTTPS is the way to go in order to be on the safe side.

EDIT: As for your second question, a simple/basic method to prevent automatic requests is to check the Referer and Origin headers of each request. This way you can filter out any off-site requests. Another option is to limit the number of requests per time interval for the same combination of IP address and user agent details. Neither of these methods is completely safe, but can be combined with a solid captcha test.

adriann
  • 396
  • 2
  • 12
  • Is it possible over SSL? Please, take look at the original post. I made an edit. – Nick Keroulis May 16 '15 at 20:35
  • HTTP over SSL will encrypt the data that you pass around, it will not prevent automatic requests. Using Referer checking, IP checking, captchas, CSRF tokens, or a combination of them can solve this. Depending on your context, you should at least do a Referer verification. – adriann May 16 '15 at 21:26
0

Use sessions.

Create a new session identifier every time the user/client accesses your registration page and then use that to validate the request. You see that's the main idea behind captcha in the first place. Or better yet:

<?Php
session_start();

if(isset($_SESSION['input1'])
&& isset($_SESSION['input2'])
&&(strtoupper($_SERVER['REQUEST_METHOD']) === 'POST'
|| strtoupper($_SERVER['REQUEST_METHOD']) === 'GET'))
{   if(isset($_POST[$_SESSION['input1']])
    && !empty($_POST[$_SESSION['input1']])
    && isset($_POST[$_SESSION['input2']])
    && !empty($_POST[$_SESSION['input1']]))
    {    //PROCESS YOUR POST DATA HERE
         $myInput1 = sanitize($_POST[$_SESSION['input1']]);
         $myInput2 = sanitize($_POST[$_SESSION['input2']]);
         echo "My variables are {$myInput1} and {$myInput2}.";
         //AND ET CETERA
    }
    else
    {    session_unset();
         session_destroy();
         echo <<<REDIRECTION
         <script type='text/javascript'>
             alert("You've had a premature detonation. Call 911.");
             window.location.replace('{$_SERVER['PHP_SELF']}');
         </script>
REDIRECTION;
    }
    clearsess();
    exit();
}

function sanitize($variable,$conn=NULL)
{    if ($conn != NULL)
        return mysqli_real_escape_string($conn, filter_var($variable, FILTER_SANITIZE_STRING));
    else
        return filter_var($variable, FILTER_SANITIZE_STRING);
}

function createForm()
{   $_SESSION['input1'] = rand(1111,9999);
    $_SESSION['input2'] = rand(11111,99999);
    return <<<NEWFORM
    <form action = '{$_SERVER['PHP_SELF']}' method = 'post'>
       <input  type='text' name='{$_SESSION['input1']}'>
       <input  type='text' name='{$_SESSION['input2']}'>
       <input type='submit' value='submit'>
       <input type='reset' value='reset'>
    </form>
NEWFORM;
}

function clearsess()
{   if(session_id() != '' && empty($_SESSION))
    {  session_unset();
       session_destroy();
    }
    session_write_close();
}
?>
<html>
<head></head>
<body>
<?Php echo createForm(); ?>
</body>
</html>
<?Php clearsess(); ?>

Well you can use it hand in hand with captcha though. Captcha would definitely be using sessions too.

RJBaytos
  • 71
  • 1
  • 8