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


35

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


26

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


21

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


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


19

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


17

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


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


13

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


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

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


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

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


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

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


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


8

There are two main (security) reasons to do this, above and beyond just using parameterized queries: Parameter type enforcement Least privilege. The principle of Least Privilege requires you to allow any entity (user or application) access only to whatever it needs to do the defined task. If you don't restrict the webapp only to the SPs, the ...


8

There is very little information in your question, so it is difficult to give a concrete answer. Before your blame the hosting company or even sue them, you should review your own program code, including all libraries and web applications you have installed. You should especially look for SQL injection, shell code injection, various ways of remote code ...


8

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


8

In addition to the other answers, one method I use for database fingerprinting (especially where the injection is blind and not data is returned) is differences in syntax between database engines. There's a good sample on slide 34 of this presentation which I tend to use. So a good example is string concatenation. MS-SQL and DB2 use + whereas Oracle ...


8

The issue is not as much direct object references as it is insecure direct object references. For example, let's say you have a script that displays a private message, and that script takes an ID as a parameter. If you view the list for your user, you'll see links to the messages you have access to. But if you can change that ID in the parameter, and use ...


8

Since injection attacks exploit control sequences in the way the output is interpreted, and since different output formats use different control sequences (think JavaScript versus SQL versus HTML), your sanitization technique needs to reflect where the output is going. If you sanitize for output upon input, you're making an assumption about where that output ...


8

As long as the DB server is properly secured and the credentials are properly linked to IP addresses that he doesn't have access to, then he can't do anything with them, but it removes one level of protection and if he does find a way to access the DB, then you are hosed. This is called defense in depth. Multiple mechanisms prevent a compromise, however if ...



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