5 ms·

> As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card

> As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card number and PIN have all be blown away. I'm quite sure this is a sign of poor development, regardless of the form being validated on the server or the client. There is no reason for the server not to send back a fully pre-populated form.

Can_Not 9y ago
Credit card info, passwords...
- naasking 9y ago
  You're already submitting it to the server. It's no less secure sending it back if there's a problem.
  - zbentley 9y ago
    This comment displays a worrying misunderstanding of web security. Sending passwords (or credit card numbers or other scary stuff) in plaintext over the wire is bad. Hash them securely (well, as securely as you can on the client side). Sending them twice is worse. Storing them with the session data on the backend so that they can be sent back to the client to repopulate a form is way worse, since more than one webserver may be handling a session, that plaintext data will have to be stored in a centralized database (e.g. memcached), which is really really bad, even if that storage is temporary. Some web forms get around this by just sending back the lengths of the individual fields so they can be masked when the form is repopulated, but that's less common and is something that doesn't occur to lots of developers (store the length, but don't send the whole string). Instead, it's easier to follow the mantra of "never store the passwords in plaintext, never send them over the wire in plaintext". Which is why most web forms clear out the sensitive fields when repopulated via the server. TL;DR it is much, much less secure to do this.
    - naasking 9y ago
      > This comment displays a worrying misunderstanding of web security. Sending passwords (or credit card numbers or other scary stuff) in plaintext over the wire is bad What are you talking about? Who said anything about plaintext? And no one said anything about sessions either. If you're submitting to the server in plaintext, then returning in plaintext is no less secure, but you're stupid for not submitting over https which is free. If you're submitting to the server over https then it's definitely no less secure to return the data.
    - samsonradu 9y ago
      Think you're a bit confused about how it all works. There is no need to use plaintext, we'll assume we're using https by default. You are already sending the data from the client to the server, I can as well echo it back with a couple of validation errors. I don't see the security hole in this situation, you do realise that regardless of the obfuscation you see in your password input fields, which by the way only protects from over-the-shoulder peeking, you are willingly sending data to the server and it will end up there unencrypted anyway. Otherwise there wouldn't be possible to do any operation at all.
      - Can_Not 9y ago
        Security operates in layers. TLS isn't the end-all, be-all for security. It's one layer that prevents a category of attack vectors. Every extra unnecessary sending or storing of sensitive data is an attack vector.
        samsonradu 9y ago
        Again, we're not storing anything. And in our case TLS is the layer we're using for protecting our data in-transit. You rely on it as a client when you send the form to the server. Can you give me an example where POST-ing a form would be secure but responding with the data adds another attack vector? They're both protected by the same "layer" of security, isn't it? How is one more vulnerable than the other?

Can_Not 9y ago

Credit card info, passwords...

naasking 9y ago
You're already submitting it to the server. It's no less secure sending it back if there's a problem.
- zbentley 9y ago
  This comment displays a worrying misunderstanding of web security. Sending passwords (or credit card numbers or other scary stuff) in plaintext over the wire is bad. Hash them securely (well, as securely as you can on the client side). Sending them twice is worse. Storing them with the session data on the backend so that they can be sent back to the client to repopulate a form is way worse, since more than one webserver may be handling a session, that plaintext data will have to be stored in a centralized database (e.g. memcached), which is really really bad, even if that storage is temporary. Some web forms get around this by just sending back the lengths of the individual fields so they can be masked when the form is repopulated, but that's less common and is something that doesn't occur to lots of developers (store the length, but don't send the whole string). Instead, it's easier to follow the mantra of "never store the passwords in plaintext, never send them over the wire in plaintext". Which is why most web forms clear out the sensitive fields when repopulated via the server. TL;DR it is much, much less secure to do this.
  - naasking 9y ago
    > This comment displays a worrying misunderstanding of web security. Sending passwords (or credit card numbers or other scary stuff) in plaintext over the wire is bad What are you talking about? Who said anything about plaintext? And no one said anything about sessions either. If you're submitting to the server in plaintext, then returning in plaintext is no less secure, but you're stupid for not submitting over https which is free. If you're submitting to the server over https then it's definitely no less secure to return the data.
  - samsonradu 9y ago
    Think you're a bit confused about how it all works. There is no need to use plaintext, we'll assume we're using https by default. You are already sending the data from the client to the server, I can as well echo it back with a couple of validation errors. I don't see the security hole in this situation, you do realise that regardless of the obfuscation you see in your password input fields, which by the way only protects from over-the-shoulder peeking, you are willingly sending data to the server and it will end up there unencrypted anyway. Otherwise there wouldn't be possible to do any operation at all.
    - Can_Not 9y ago
      Security operates in layers. TLS isn't the end-all, be-all for security. It's one layer that prevents a category of attack vectors. Every extra unnecessary sending or storing of sensitive data is an attack vector.
      - samsonradu 9y ago
        Again, we're not storing anything. And in our case TLS is the layer we're using for protecting our data in-transit. You rely on it as a client when you send the form to the server. Can you give me an example where POST-ing a form would be secure but responding with the data adds another attack vector? They're both protected by the same "layer" of security, isn't it? How is one more vulnerable than the other?