Hot answers tagged databases
42
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. ...
33
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 ...
18
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 ...
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, ...
16
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 ...
13
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 ...
12
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 ...
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 ...
11
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 ...
11
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
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
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 ...
11
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 ...
10
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 ...
10
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 ...
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 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
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 ...
7
There are unwrappers available for code wrapped with the Oracle 10g and 11g mechanism. These include both an online 'unwrapper' and the source code of an unwrapper written in Python.
As such, wrapping will do little to prevent someone with that level of access obtaining the source code.
Additional indicators of the nature of the code can be obtained using ...
7
[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 ...
7
You are extending your trust to outsiders beyond your subnet neighbors.
By default, MySQL uses unencrypted connections between the client and the server. This means that someone with access to the network could watch all your traffic and look at the data being sent or received. They could even change the data while it is in transit between client and ...
7
These three properties are usually known as the CIA triad: confidentiality, integrity and availability. They are the three main classes of security properties of any system (though not all properties fit within those three classes).
Confidentiality (i.e. secrecy) means that an attacker cannot read data that she is not supposed to be able to access. An SQL ...
7
I recommend incrementally switching each user over to the new password hashing method on their next login. At that point, you know their cleartext password, so you can re-hash it with bcrypt and switch them over to bcrypt. This avoids the need for a "flag day" or contacting all your users. In fact, it is invisible to users: your users never need to know ...
7
I think what is being talked about are "Stored Procedures". Triggers are fired internally in the database when actions are performed, but stored procedures are direct parameterized functions.
Why are triggers (stored procedures) not often used to secure a database?
Sometimes laziness, sometimes it's just too restrictive. It's also the case that using ...
7
There's no DBMS that does that.
The main problem is that there is no way for a database server to tell what parts of an SQL query were generated from user input, so no way to disallow queries that were formed with user input. Once your pieces are added into one string, you can't get it apart to work out what was what any more.
However, what a DBMS could ...
6
I suppose the usual OS methods (including fail2ban if remote ssh admin is required), then block all external access to the MySQL port, or allow a whitelist to connect if absolutely necessary. Set a password for the mysqladmin user.
After that, the mysqladmin user should only be allowed to connect from localhost and should be the only user granted any ...
6
Your requirements aren't cloud specific. This same solution will work with a traditional hosting. The hallmark of cloud computing is dynamic resource consumption by booting up VM's only when you need them.
1)As far as I know MongoDB doesn't support SSL. In order to have a secure connection to MongoDB you'll have to use a VPN to create a safe tunnel.
...
Only top voted, non community-wiki answers of a minimum length are eligible
