www.webdeveloper.com
Results 1 to 8 of 8

Thread: Form posting data protection

  1. #1
    Join Date
    Dec 2008
    Posts
    488

    Form posting data protection

    I've been learning about security using SSL, PHP crypt(), and some other methods, but my question is, how is the data sent in a form protected from being intercepted before it reaches the server? From what I can tell, it doesn't get encrypted until it reaches the server, then it's on to the database and back to the user again.

    Dost the POST method actually encrypt the form data in some way that is instantly decrypted by the server? I thought of using a javascript encryption just before the data is sent by the client, but if a person is smart enough to intercept data, surely they would be able to figure out the javascript location, which means they could easily decrypt it.

    When you send your credit card number to an online store (assuming we're talking about a professionally secured store) , obviously they're not just going to let you send your card number all bare and naked to their server before they can encrypt it, right? I would think they have the technology in place that would allow the browser to encrypt before the POST is sent. In addition, the technology would have to be invisible to the user, so that people can't see what encryption method is being taken. Javascript can't really do this.

    So, how do they do it? How does Bank of America protect your information before it gets to them?

  2. #2
    Join Date
    Jun 2003
    Location
    here
    Posts
    4,551
    First of all javascript encryption is false security, it can be easily reversed and only means that you limit the functionality of your site to around 10%(OK, that changes a lot based on who you listen to, but I've seen it quoted as high as 17, but never lower than 5) of visitors, not a good idea.

    Are you sure you understand the idea of SSL? It's encryption that is compatible on almost all browsers.

  3. #3
    Join Date
    Dec 2008
    Posts
    488

    Exactly

    First of all...
    That's what I'm saying--javascript is useless for site security.

    No, I don't fully understand the SSL security. From my interpretation, SSL ecrypts the data sent from the server to the browser. Does that mean it also allows the browser to ecrypt anything sent to the server? That's what I was asking.

  4. #4
    Join Date
    Jun 2003
    Location
    here
    Posts
    4,551
    SSL is a secure connection, information is encrypted both ways.

  5. #5
    Join Date
    Dec 2008
    Posts
    488
    Thanks, that's what I needed to know. I appreciate your help. Do you think any additional measures should be taken client side to ensure security? From what our IT guy is saying is that there was a scare recently about a possible intercept before the handshake takes place, through the traceroute, where the eavesdropper can get the keys, which eliminates the security of the HTTPS. Is that worth looking into?

  6. #6
    Join Date
    Jun 2003
    Location
    here
    Posts
    4,551
    # SSL v2 does not have any protection for the handshake, meaning a man-in-the-middle downgrade attack can go undetected.
    SSL v3 is supported by the latest version of all major browsers(firefox2+, IE7.0.2+, safari(don't know from when) and opera9), which does include protection from man in the middle attacks(Do not assume said security is 100% secure, it's still possible, there are just protections put in place to try and prevent it).

  7. #7
    Join Date
    Dec 2008
    Posts
    488
    So basically, if you want to cater to all users, you must use SSL v2, which leaves you open to this man-in-the-middle attack... We definitely can't afford to lose users, but we can't afford leaking their information almost as much. I'm guessing even the top sites have vulnerability to this type of attack?

  8. #8
    Join Date
    Jun 2003
    Location
    here
    Posts
    4,551
    It doesn't work like that, SSL v3 is backwards compatible, so if SSL v3 can not be used it seemlessly falls back onto v2, with a lot of effort, it's possible to see this in action(I've only ever been able to do this on firefox3, and it means you need a very configurable firewall to let you log the whole handshake as it happens after temp turning off SSL v3).

    There is a very small chance of SSL v2 being intercepted anyway, it's not a very easy hack to execute, since the handshake is sent in multiple packets, and the routes they take are often not direct(and even then they need to intercept both the whole handshake(or rather about 95% of it is required, but that's if you only want specific packets), then intercept the whole communication transmitting the details, the odds of these going through the same man in the middle is very, very small).

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center



Recent Articles