• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

What are the security concerns?

H

Hmongkeysauce

Senior member
How safe is it to collect sensitive data(SSN, etc) over the internet, using only javascript to validate user input, storing the data on a text file on the server, and doing it all on a shared hosting account over non-HTTPS?

Thanks.
 
Hmongkeysauce said:
How safe is it to collect sensitive data(SSN, etc) over the internet, using only javascript to validate user input, storing the data on a text file on the server, and doing it all on a shared hosting account over non-HTTPS?

Thanks.
Click to expand...

[SARCASM] Just reading that makes me want to avoid any sites you run.

Seriously, just image what your users would feel if you asked them that question? If you are going to collect sensitive data, then I say you'd better AT LEAST be using HTTPS.

I'm not a security guy, but that alone is a problem for me. And if I'm having such issues, then real folks will have even bigger concerns.

-chronodekar
 
Enough to make me -- and I'm probably the least security sensitive of my friends -- want to smack you for asking.
 
NEVER trust client side scripting for user validation. You can use it along with server side validation just to make the client experience better, but don't rely on client side validation ever for data sensitization.

Even something like a select box or a radio button is equivalent to just a text field... validate all of those server side.

Remember that fusetalk avatar bug? Yeah, that was a case of client side validation. It would only display the avatars you are allowed to use, but the server would not check if the user actually selected one from the list.

Also people will be very reluctant to give their SSN or other sensitive info. If it was that easy I would be using SSN when people register on my game server, so I can limit number of accounts per person, and make perma bans, permanent. So would forums, etc. But it does not work that way. People wont want to give their SSN, and for good reason. It's hard to trust people online these days. There's lot of sites that may look legit but they're actually run by a bunch of scammers.
 
This smells like homework to me. It can't possibly be a real-world question. So to answer it, you should think about the layers involved in the transaction, and where the vulnerabilities lie. If security is the sole question, and not data integrity, then the use of javascript for client-side validation is probably not your primary concern, since there is no database to suffer an injection attack. The key point is that you're sending the kind of information that is useful to identity thieves over a plain text connection and storing it in a text file. Can that be done securely? In strict terms, no. The plain text connection means nobody will ever consider that setup secure. The server-side pieces could be made secure with careful design and administration, but obviously nothing about the proposed scenario is close to ideal.
 
Really, Really, Really, bad idea. As a snot nosed teenager, I was playing with a packet sniffer to try and cheat at a game (long story). While doing this, someone sent an email. BAM, I suddenly had a persons username and password.

Yes, I quickly deleted that username and password. However, it was incredibly easy for me to get it.

If you are sending data unencrypted over the internet, you are basically handing that info to every snot nosed teenager with a packet sniffer en route to the server. If you wouldn't trust the data with an identity thief, then you should encrypt it. Not only that, but you should use GOOD encryption. (RSA, DES, ect).
 
Thanks for the replies.

No, this is not a homework question. I'm too old for homework 😀. And fortunately, I didn't set this up. Someone else did though. And now, I have to explain to the person why its a big no-no.
 
Hmongkeysauce said:
Thanks for the replies.

No, this is not a homework question. I'm too old for homework 😀. And fortunately, I didn't set this up. Someone else did though. And now, I have to explain to the person why its a big no-no.
Click to expand...

There have been some good replies here. I hate the idea of ignorant people losing their identities on the internet, so I'm going to reiterate the ideas and add my own.

-The worst part of the above is that information is collected in the first place. I'm just going to throw that out there.

-The most glaring technical flaw is the lack of encryption on the submission. This is fairly dangerous.

-Lack of a database is actually not that bad -- its unconventional perhaps but not that bad. Databases are not more inherently secure than text files. It is the server security in general that I worry about. Of course, it should have remote root disabled, strong passwords, etc., and should be well administered by a paid professional.

-Lack of form validation is a huge security problem too -- client-side obviously will not cut it for reasons pointed out above. Actually, the its-a-text-file thing is a feature against injection attacks in this case, because there's nothing to inject, but even so, vulnerabilities can still exist in other layers of software.

If you only fix one thing, fix the encryption.
If you only punt on fixing one thing, warn people that their personal information isn't encrypted.
 
Perhaps someone more knowledgeable about IT Security than myself could comment, but in the current states, would information not be susceptible javascript injection in order to extract data?

-Kevin
 
Gamingphreek said:
Perhaps someone more knowledgeable about IT Security than myself could comment, but in the current states, would information not be susceptible javascript injection in order to extract data?

-Kevin
Click to expand...

That all depends on the backend script handling the data storage and how it was written.
 
Hmongkeysauce said:
Thanks for the replies.

No, this is not a homework question. I'm too old for homework 😀. And fortunately, I didn't set this up. Someone else did though. And now, I have to explain to the person why its a big no-no.
Click to expand...

Oh well, that's different. You could give this person a technical explanation, but the reality is this: collecting this information in the manner described is professionally and ethically irresponsible, and even if they have a banner across the page in 72pt type notifying users of exactly what they are doing, they are still opening themselves up to massive civil liability in the event of a breech. I would literally stand up, right now, walk over, and press the power button on that server.
 
Markbnj said:
Oh well, that's different. You could give this person a technical explanation, but the reality is this: collecting this information in the manner described is professionally and ethically irresponsible, and even if they have a banner across the page in 72pt type notifying users of exactly what they are doing, they are still opening themselves up to massive civil liability in the event of a breech. I would literally stand up, right now, walk over, and press the power button on that server.
Click to expand...

I would cut the Ethernet cord as well 😛
 
Gamingphreek said:
Perhaps someone more knowledgeable about IT Security than myself could comment, but in the current states, would information not be susceptible javascript injection in order to extract data?

-Kevin
Click to expand...

The danger of using solely client-side validation is that users can turn it off, and put what they want in form fields that are posted to the server. So the base problem is that you lose control over what is posted.

What kind of problem that really is depends on what happens to that form data on the back end. If the form fields are concatenated into a text SQL command that is sent to a server verbatim, that's very bad. In that case SQL injection can be used to get the server to return almost anything you want.

If the form fields are used to initialize arguments to a parameterized query, that is less bad. The query will go boom, and then the app will likely go boom (since the designers are already proven idiots), but you can't get the server to do evil.

If the form fields are simply concatenated into a string that is written to a text file, that is the least bad security-wise. No script engine is going to process what is in them, and they cannot be used to get the server to do things the developers didn't want it to do.

But they can fark up the data in the text file, obviously.
 
Again, thank you for all the responses. I'm currently doing a write up of this mess for my boss. However, the business owner of this particular application still need the application. I'm no expert in the security world, so what needs to happen before we can even think about putting this application online again? I do coding(C#), but I have never needed to collect sensitive data, especially over the internet, before. My initial thoughts, and from the responses I got so far, are to get better hosting(VPS? Simply because the VPS can used for other things in the near future), server side validation, use database for data storage, and use HTTPS. What else do I need to investigate/look into?
 
Hmongkeysauce said:
Again, thank you for all the responses. I'm currently doing a write up of this mess for my boss. However, the business owner of this particular application still need the application. I'm no expert in the security world, so what needs to happen before we can even think about putting this application online again? I do coding(C#), but I have never needed to collect sensitive data, especially over the internet, before. My initial thoughts, and from the responses I got so far, are to get better hosting(VPS? Simply because the VPS can used for other things in the near future), server side validation, use database for data storage, and use HTTPS. What else do I need to investigate/look into?
Click to expand...

Collecting and storing social security numbers is serious business. At the very least you need: a well-written front end with client- and server-side validation of input parameters; an SSL connection and valid server certificate; a server process that uses parameterized queries or stored procedures to insert the records; a modern, secure database such as SQL Server, preferrably located on a separate machine, behind a firewall, and accessed by a separate database account whose credentials are not found anywhere in the text of the web application files; a regime for managing backups and making sure old backups are destroyed and current backups are always completely accounted for; logging of all internal changes to the system, along with a regime of restricted access that keeps people who shouldn't be in the system out; active system administration and intrusion detection; yearly audits of all of the above.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top