Tag Info

Hot answers tagged

44

Think about it this way On one hand, there's nothing wrong with it. If your application is secure enough against SQL Injection, then an attacker won't be able to do much with that information. Unless you're naming your tables table_2231 and your columns column_4231 (in which case I hate you), it's not gonna be difficult to guess your tables names anyway. ...


39

Why can't we escape all user input using "magic"? At the time the magic is applied, it is unknown where the data will end up. So magic quotes are destroying data that, unless it is written unescaped to a database. It may just be used in the HTML response sent back to the client. Think of a form that has not beem filled in completely and is therefore ...


33

It's like, "Put the jewelry box outside the house so that robbers won't bother getting in for the TV?" Yes, it is exactly like that. If you don't care about the value of the database, relatively speaking, then sure it makes sense to leave it outside - if the assumption is that the application is horridly insecure, but you need to put it up anyway ...


30

DOT's backend Oracle database is down due to ORA-27101. ORA-27101 has a nice explanation here with a useful reader comment stating that it happened to them because the Windows Event log was full. From the output, you can learn that they have Oracle, Java JDBC, Drupal, ColdFusion. You also see some SQL code. With that knowledge you can start digging for ...


27

Assuming that You're 100% sure that your database server only accepts local connections. You're 100% sure that the attacker doesn't have access to the local environment from which connections are allowed. You're 100% sure that the application that uses the database is otherwise secure. You're 100% sure that those credentials aren't used for anything else ...


23

SANS' "Making Your Network Safe for Databases" (http://www.sans.org/reading-room/whitepapers/application/making-network-safe-databases-24) reads a little dated in some sections, but provides a decent "for dummies" level of guidance in the direction you're after. You could also exhaust yourself poking through the US NIST's resource centre ...


22

Run only MySQL on the Server - If possible run only MySQL on the server and remove any unused services. Firewall - Limit access by IP address to only the servers / clients that require access. User Privileges - When creating users always give the minimum amount of privileges and expand as needed. Also try to avoid using '%' wildcard for hosts and instead ...


20

One explanation I haven't seen here is that many financial institutions are tightly integrated with older systems and are bound to the limitations of those systems. The irony of this is that I have seen systems that were built to be compatible to older systems but now the older systems are gone and the policy still must exist for compatibility with the ...


20

General comments. It sounds like it would be helpful for you and your boss to learn some basic security concepts, before proceeding. Security is a specialized field. You wouldn't ask a random person on the street to perform open-heart surgery on you; and you shouldn't expect an average software developer to know how to secure your systems. I sense some ...


19

NoSQL databases are relatively new (although arguably an old concept), I haven't seen any specific MongoDB hardening guides and the usual places I look (CISSecurity, vendor publications, Sans etc all come up short). Suggests it would be a good project for an organisation, uni student, infosec community to write one and maintain it. There is some basic ...


18

Hashing passwords is a defense against a specific attack. The attack is: stealing a copy of the entire password file (users table, ldap db, etc), downloading it to one's computer, and attempting to retrieve the users' passwords. The goal of the attack is: to find users who reuse their usernames and passwords across websites, and log into those users' email, ...


16

The best placement is to put the database servers in a trusted zone of their own. They should allow inbound connections from the web servers only, and that should be enforced at a firewall and on the machines. Reality usually dictates a few more machines (db admin, etc). Obey reality as needed, of course. They should only be making outbound connections if ...


14

Exposing table names might have broader consequences than you expect. For instance you could be putting your company at legal disadvantage by disclosing a table names like "deleted_messages", "profile_views", "single_female_users" etc. Retention of that data and user privacy suddenly becomes a topic of discussion and can cost much. You cannot always control ...


14

If he can't access the database, the credentials are meaningless. It's like having a key to a door that's inside a guarded military bunker hidden in a remote location in the Gobi desert. The key is only useful if you can get to the door. That being said, it'd be very bad practice to let your credentials leak out like this. If you suspect that they're ...


14

SSL Connection to the server so no one can sniff passphrases or data over the network. Don't forget your backup: it should be encrypted too. The key should be stored independently so if someone gains access to the backup he cannot use the data. Depending on your country of residence there can be legal requirements for health data protection. Manage access ...


14

If the database holds card details, it can be very easily argued that you aren't fulfilling the PCI DSS requirement on appropriate protection. It also fails the sanity checks on single points of failure, and protecting your core assets. If the data is worth billions, why would you not spend a few thousand more to add layers of protection? Industry good ...


13

Rather than two separate connections working together, you can use separate user accounts with access to specific columns. Most of your statements can use the user account that has access only to the username (not password) column of the users table, and the less important data from your main db. In MySQL, you can do this with nice granularity. This will ...


13

Generally hashing and encryption are for two different things. The main distinction in your case is that hashing is one way, and encryption is two-way. That is, you can decrypt the password to get them in plain text, but you cannot "de-hash" something. If your system gets compromised and you are using encryption, the attacker will probably have all the ...


13

I don't understand how these database tables are accessed. Surely it is not SQL Injection, as that should be a thing of the past with prepared statements, Ahhh assumptions.. Have you seen the OWASP Top Ten project? SQL injections have always been a constant source of security issues. I cannot see how changing any session state would effect the ...


13

The primary reason not to use AES_* functions in MySQL is because they are using ECB block mode of operation, which is insecure. Read more at: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation Edit: Since MySQL 5.6.17 things have changed and MySQL supports CBC block mode, but it has to be enabled manually. Read ...


13

SQL Server has the option to encrypt the connection between application and database. When you operate SQL server in an untrusted environment, it is recommended that you enable it. When you do, hashing the passwords before sending them to the database is unnecessary as long as you trust your DB administrator. Additionally, most deployments of SQL server ...


12

What about the support cost? Let's say that we allowed anyone to create password consists of € chars. Hurray, we are able to use special characters in our passwords. But wait - how on earth we can type that password if we want to get the access to our bank from the mobile-phone? It's easier to type € from our keyboard than from the mobile phone. What about ...


12

[1.] Why can't we escape all user input using "magic" ? Because magic quotes are broken on two counts: Not all $_(REQUEST/GET/POST) data goes into the DB. And for you to make any sense of it, you have to de-escape the input. They're the addslashes equivalent (see my note on [2.]), hence they're not actually secure. [2.] Why wasn't addslashes ...


12

Yes it is possible, and this technique is widely used. It does have some minor drawbacks compared to stateful sessions: It does not support strong logout. If a user clicks logout, the cookie is cleared from their browser. However, if an attacker has captured the cookie, they can continue to use it until the cookie expires. The use of a server-side secret ...


11

The standard way is to put the credentials into a config file, and attempt to protect the config file from being more readable than the perl file. This offers a moderate increase in security; for example, the code may be in source control and accessible to developers, the config file wouldn't be. The code needs to be in the web server's cgi root, and ...


11

A hash computed over the plaintext would have the right characteristics for an IV, as far as "uniform randomness" is concerned. This is for a cryptographically secure hash function, not a CRC. Rather, something like SHA-256. A CRC is in no way secure enough for cryptography. However, the IV must be known to whoever will decrypt, so it must be stored along ...


11

The first few that come to mind are: An SQL injection attack where the database user in question has only the SELECT privilege. A compromise of the primary database backups or the offsite database backups. While these aren't read only, there's little likelihood of escalating the compromise by writing to backups. A compromise of a shell account on a ...


11

The concept is that on a given "object" (say, a file), you have access permissions which detail who can access the object and under which conditions. The owner is an optimization: usually, among all the users who have permissions for a given object, one of them should have "all the permissions" and be generally considered as responsible for this object. On ...


11

As far as I can tell, this scheme doesn't make any sense. As you've noted, you still need to store the plaintext email address for the user, so there isn't any significant security benefit to using the plaintext email and email + password + salt hash vs just using plaintext email and password + salt hash. As I'm sure you've already noted, without the ...



Only top voted, non community-wiki answers of a minimum length are eligible