I was intending to release a website to the public that stored sensitive information on the client side using Local Storage such as API keys. Variables stored in Local Storage are used in my PHP scripts.
I was thinking, since it had an SSL certificate, this would suffice for storing sensitive information such as an API key and secret.
My website will not have ads. The website also has a MySQL database.
I am going to configure a general user for reading data in since a user does not need write privileges (it is a read-only site). The problem is if they went on a malicious website later on, they could extract these Local Storage keys (maybe with a script) and potentially hack my consumer.
The names are very generic on my website when creating and using the keys so it would be hard to identify the origin of the keys or what their purpose is.
Is this wrong to do this to my consumer?
Yes, it is wrong. It means a huge security leak. Imagine the case when any malicious Javascript is executed in the browser for any reason. It will be able to read the content of localStorage and send it to the hacker.
This could be caused by a website problem, such as possibility of XSS injection, but a browser extension with malicious content can achieve the same. While XSS injection can be protected against, if the developers of the site are careful, what browser extensions the users will install is beyond your control. Avoid this approach. Store sensitive data safely on the server.
Related
I've edited this question. I hope this version is a bit more clear.
I am seeking to have a programmer build a process for me. I need to ensure what is recommended is a best practice for the below process.
Here are the steps I need to have built:
Have a https: webform on my server that submits client inputted data into a database on my server. The data is personal identifiable information and needs to be securely transmitted in the next step.
Once the data is loaded in my database, I need to transfer the data in an encrypted/Json format to a third-party server. The third-party will unencrypt the data, score it and send it back to my server encrypted.
While the data is being sent and scored by the third-party, the client will see a browser screen indicating processing...
Once the data is scored and sent back to my server, it will be unencrypted and it will update the client's browser with options based on the score given by the third-party.
Based on what I understand, I think an API on both my server and the third-party server might be best.
What is the best practice approach for the above process?
Below are some questions I have which would be very helpful for me to understand in your response.
Is the API approach the best?
What process is used by the third-party to unencrypt data I send and vice versa? How do I prevent others from unencrypting the data if it is intercepted?
3)While the data is being scored by the third-party, the client browser will show processing. From a web development standpoint how does this work? Also, from a web development standpoint, how exactly is the processing screen triggered to update with results on the client's browser screen when the data is sent back from the third-party?
The file that you will be transmitting, as you mentioned is encrypted so it will totally depend on the encryption algorithm you are using, generally encrypted data are stored as BASE64 or HEX so after encryption the data will be passed in the above-mentioned format.
To answer you second question on "how will the receiving website receive the file?", there are several ways you can do this:
You can share the backend database your website is using then it will just be a simple query away (by shared I mean both the websites use the same database).
Another way of achieving this is to use an API which can store your data and can be globally used in any application it is called at
Or you can set up a simple php server locally at your machine and send data between websites using the HTTP: GET or HTTP: POST requests.
also avoid using un-necessary tags like web-development-server or data-transfer or transmission etc. these tags are useless and unrelated to your question. You should only tag those which are related to your question, a simple tag for web-development would be enough.
also edit out your question to make us properly understand, what problems you are facing? what have you tried? what do you expect from us in the answer?
please clarify your question more.
Your concept of files being sent around is kind of wrong, because in most cases none of this is ever been written to disk, and so there is no JSON file with a file-name - and these are not directly being encrypted, but only pushed through an encrypted channel. Most commonly both sides either use HTTPS or WSS as the protocol, which encrypts / decrypts the data being exchanged transparently (all by itself). And depending on the protocol which is being used, this requires either a combination of client & server, server & server - or a P2P network - to be installed.
Further reading: Internetworking Basics - Computer and Information Science.
I am building a chrome extension that needs to persist user sensible data.
I know that you can use HTML5 but it is vulnerable to XSS, and possibly other form of attacks. I recently found out about chrome.storage but the docs say:
Confidential user information should not be stored! The storage area
isn't encrypted.
Now my question is:
Is there a secure way to store sensitive user data (i.e. a private key) in the browser?
The default content security policy pretty much protects you from XSS assuming you don't do anything really stupid. You could use some sort of a library to to encrypt local data and make users enter a passphrase to decrypt the data. The attack vectors at this point are more around malware on the computer and other people with physical access. Chrome extensions themselves are well protected from other sites.
Ultimately though, anything installed on the computer or having access to the computer has the potential to access the private info regardless of what you do. My recommendation would be make sure users are aware of how sensitive the data being stored is and that they need to maintain proper security precautions around getting access to the computer.
I have an encrypted connection from my ios app to my mysql database. My question is whether or not they would be able to intercept the connection form the ios app and find the domain with or without an encryption
whether or not they would be able to intercept the connection form the ios app
Yes, they would be able to do so. At least surely using a jailbroken device - for jailbroken devices, there are a couple of factors that make hacking easier.
On the one hand, on a jailbroken system, it is possible to prevent Apple's encryption of the app executable (by dumping the unencrypted program code from memory to the disk) and run a utility called "class-dump" to obtain the Objective-C class information (it is also possible to use the GDB debugger on the device or IDA Pro in order to reverse engineer the application logic).
On the other hand, the same MobileSubstrate library that is used for making iOS tweaks can be used to alter the behavior of any given application (I have successfully used this technique for circumventing some code obfuscation at runtime), so in theory an attacker would alter the communication logic of your application and dump the unencrypted data of yours and your users.
On the gripping hand, most standard and less-used Unix utilities usable for such kind of hacking are ported/compiled for jailbroken iOS - including the popular network sniffing tool nmap, the "John the Ripper" password cracker, the infamous aircrack-ng WEP/WPA key cracker, the GNU debugger (GDB), etc. These are also useful for executing an attack you described.
If the connection itself is encrypted, then, in theory, your data should be safe while in the wire. This still doesn't prevent the MobileSubstrate-based approach to exploitation. It is also true that the IP address of the server you're connecting to can be found relatively easily (end even the domain it is matching, since there are also known techniques for obtaining reverse-DNS information using a known IP address).
I'm not sure if this is possible without a jailbreak, but a similar man-in-the-middle attack was performed against Apple's in-app purchases by a Russian hacker (effectively rendering ineffective the underlying payment system and allowing purchases to be freely downloaded), merely by requiring users to install SSL certificates, profiles and using the hacker's own proxy server, so I'd suspect it is possible even without a jailbreak. Note that in this case the connection was also encrypted, and it was not the encryption that mattered.
You should not imo create a direct connection to the mysql-database but instead pursue a connection with a server program/api with a connection to the database in question. To answer the question more directly users should not be able to intercept the connection from the ios-app if it is encrypted correctly but still, is it worth that risk?
If the connection is encrypted, the data are secure. But not the domain. The iPhone is connecting to an IP Address, and that IP Address is obviously not encrypted.
Create a PHP interface between your app and the Mysql. Doing this they will be able to hack only app-accounts not the entire database! Your Mysql credential will be stored in the remote domain where the PHP code runs.
Would be a good or bad idea to use localStorage for sensitive data (assuming the current HTML5 implementations)?
What methods can I use to secure the data so that it cannot be read by a person that has access at the client computer?
Bad idea.
Someone with access to the machine will always be able to read the localStorage, there is nothing much you can do to prevent it. Just type 'localStorage' in firebug console, and you get all the key/value pairs nicely listed.
If you have an XSS vulnerability in your application, anything stored in localStorage is available to an attacker.
You can try and encrypting it, but there is a catch. Encrypting it on the client is possible, but would mean the user has to provide a password and you have to depend on not-so-well-tested javascript implementations of cryptography.
Encrypting on the server side is of course possible, but then the client code cannot read or update it, and so you have reduced localStorage to a glorified cookie.
If it needs to be secure, its best to not send it to the client. What is not in your control can never be secure.
Public Key Cryptography can be applied to prevent any kind of intrusion. Also, data integrity checks (such as CRC or hashes) may be used to make sure data is validated by the server.
Let's say that you have a standalone application (a Java application in my case) and that this application has a configuration file (a XML file in my case) where you store the credentials (user and password) for a bunch of databases you need to connect.
Everything works great, but now you discover (or your are given a new requirement like me) that you have to put this application in a different server and that you can't have these credentials in the configuration files because of security and/or compliance considerations.
I'm considering to use data sources hosted in the application server (a WAS server), but I think this could have poor performance and maybe it's not the best approach since I'm connecting from a standalone application.
I was also considering to use some sort of encryption, but I would like to keep things as simple as possible.
How would you handle this case? Where would you put these credentials or protect them from being compromised? Or how would you connect to your databases in this scenario?
I was also considering to use some
sort of encryption, but I would like
to keep things as simple as possible.
Take a look at the Java Cryptography Architecture - Password Based Encryption. The concept is fairly straight forward, you encrypt/decrypt the XML stream with a key derived from a user password prior to (de)serializing the file.
I'm only guessing at what your security/compliance considerations require, but definitely some things to consider:
Require strong passwords.
Try to minimize the amount of time that you leave the sensitive material decrypted.
At runtime, handle sensitive material carefully - don't leave it exposed in a global object; instead, try to reduce the scope of sensitive material as much as possible. For example, encapsulate all decrypted data as private in a single class.
Think about how you should handle the case where the password to the configuration file is lost. Perhaps its simple in that you can just create a new config file?
Require both a strong password and a user keyfile to access the configuration file. That would leave it up to the user to store the keyfile safely; and if either piece of information is accidentally exposed, it's still useless without both.
While this is probably overkill, I highly recommend taking a look at Applied Cryptography by Bruce Schneier. It provides a great look into the realm of crypto.
if your standalone application runs in a large business or enterprise, it's likely that they're using the Lightweight Directory Access Protocol, or LDAP, for their passwords.
You might want to consider using an LDAP, or providing hooks in your application for a corporate LDAP.
I'm considering to use data sources hosted in the application server (a WAS server), but I think this could have poor performance and maybe it's not the best approach since I'm connecting from a standalone application.
In contrary, those datasources are usually connection pooled datasources and it should just enhance DB connecting performance since connecting is per saldo the most expensive task.
Have you tested/benchmarked it?