New answers tagged

14

The worst case scenario you have to protect against is an attacker which completely compromises your server and obtains your sourcecode, your config and a dump of your database. Keep that in mind. This is the scenario in which a salt is supposed to protect your passwords. Remote brute-forcing is not impaired by a salt at all (which is pointless anyway on ...


0

I am not sure to understand what you are calling vulnerable column. But I'll try to answer your question. First of all, in order to locate such SQL injection, the easiest way is to inject mathematical operations, for instance: www.vhul-web.com/index.php?id=1 Displays result 1 www.vhul-web.com/index.php?id=2 Displays result 2 ...


0

One approach is to store such sensitive keys, passwords, or other credentials in a particular S3 bucket. That bucket should not be publicly accessible/available. Next, you create an IAM role which has S3 read-only access just to that bucket. Last, when launching your EC2 instance, you assign that IAM role to that instance. With this sort of approach, ...


0

It depends on how secure you need to be. For PCI, for example, you need to have two keys. The first is the data encryption key. The second is the key encryption key. You use the DEK to encrypt the data. You use the KEK to encrypt the DEK. It is not required but strongly recommended that you store the KEK in the keystore provided by your OS. Then only the ...


0

It depends on what you mean by "storing", as well as "server". I'm going to assume for sake of answering that there are two "servers" in use now, both on the AWS cloud: MySQL server. Application server (which currently has the code with your cryptography key in it). The MySQL server has no reason to have the key, ever. The Application server I assume ...


1

Using MySQL's built-in functions for encrypting and decrypting information is generally not recommended for exactly the reason that you described - MySQL is often configured to log queries. If that's the case, the plain text data (and the encryption/decryption keys!) are written in plain text to the logs! Having said that - If you must use aes_encrypt and ...


0

However, now I am trying to use "Type in the encryption key when you start up" and to save it in a session cookie (encrypted) but I do not know how to tell the user if his key is correct or not. Is there any reason why you are storing this client-side? The cookie will be sent with every request, and encryption here seems wrong because you will need ...


0

The typical answer is: store them in configuration files because code files are often published. A new trend seems to be to store it in environment variables, if you can control those when starting the server. On shared hosting this is not the case, and then configuration files are a fine option. After all, once someone gets to your filesystem, they could ...


0

It is never a good idea to store passwords in source code. Source code has the horrible tendency of becoming public. This can happen by an exposure in your version control system (google aws key github to read some horror stories), you share the source code with someone, a but in your PHP configuration serves your source code, etc... Also, you should be ...


0

Hanky 웃 Panky brings up good points. However, I'd like to add to them: You can mitigate damage by restricting connecting accounts by roles. Let's say you only allow searching on your website. Allowing only SELECT statements for that particular account will prevent anything else from running. This doesn't work if you have an account for each: SELECT, ...


0

No one, except a user who has FTP/SHELL/Admin access to your server can see those username/passwords if you use the code properly (and not pick up username/password from a plain text web accessible file), there is no need to worry about preventing it from being exposed to your web visitors. And there is no point trying to hide it from someone who gets ...


0

Are PreparedStatements sufficient? PreparedStatements are not sufficient on their own. You should step through your code and ask yourself what is necessary, and what is possible. Step through on both the client and the server side, and see what data gets sent, if it's possible to modify it, and what it does. See what things you can do. I can't see the ...


0

Your code handles the SQL insertion correctly. I have two guesses about the attack: The attacker could have repeated the request several times, and your code doesn't check if it has already downvoted the post. The attacker have sent a lot of downvote requests in a very short period of time, allowing him/her to exploit a time of check / time of use race ...



Top 50 recent answers are included