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. ...


38

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 ...


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 ...


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 ...


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, ...


17

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 ...


15

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 ...


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 ...


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 ...


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 ...


10

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 ...


10

[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 ...


10

Let's say you've got a query like this: $q="SELECT username, joindate FROM users WHERE username LIKE '%" . $search . "%' LIMIT 20"; Now imagine you control $search via a parameter. We would usually make it return the user passwords in the joindate field like this: $search="' UNION SELECT username, password FROM users; -- -"; As such the query becomes: ...


10

Agree with Jeff Ferland, database servers should be on their own: you should have a clean network for replication & backup. Pardon my ASCII art, a quick overview of a reasonable ideal: [internet] | outer-firewall--- [proxy-zone] | ----- [app-zone] | inner-firewall [lan]--/ \-- ...


10

If using SSL, then what PostgreSQL does is fine. If not using SSL, but still doing the authentication across the network, then what PostgreSQL does stinks. Their games with MD5 are worthless, but not because they use MD5. MD5 has its own issues, but there they are just misusing it awfully. With "cleartext password" authentication, the client shows a user ...


10

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 ...


9

You are already using parametrized queries which protects you against injection of SQL parts, assuming you are always using parameters for untrusted data. As you said that leaves the issue of wildcard characters in operators that support them. That is, if you are using "=" instead of LIKE, the problem will not arise. In most cases, in which LIKE is used ...


9

More information you expose more vulnerable you are, no matter of his priority in your security policies.



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