Hot answers tagged

77

The standard approach to this kind of issue is to create a UUID (Universally Unique Identifier) for each picture. This is generally a random 128-bit identifier which you can assign to each picture without any particular concern that it would be possible to enumerate the pictures via a brute-force attack on the namespace. For example in .NET you can use the ...


67

This is security through obscurity. While it might not hurt you in all cases, on it's own it does not provide viable security. Do not rely on this as your protection. A short parable Let's say you keep your money in a jar labeled MONEY in your house. Since you know you sometimes forget to lock the door when you leave the house, you relabel the jar ...


50

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


49

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


47

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


40

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


36

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


34

The client is the attacker. Walk around your office while chanting that sentence 144 times; be sure to punctuate your diction with a small drum. That way, you will remember it. In your server, you are sending Java code to run on the client. The honest client will run your code. Nobody forces the attacker to do so as well; and you use client authentication ...


31

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


29

I would simply use the picture hash. What's the problem with someone figuring out the hash you used? If I think "this part of the url looks like a sha1", download the file and it has that sha1, I was right. But that doesn't make me able to break your «cat security». Even if it was treatable to attempt breaking the hash to figure out the picture, there's no ...


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


27

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 (http://csrc.nist....


26

A few points: What you mean with encrypting passwords in the DB is hashing. That´s a big big difference. The first reason why DBs are used instead of hard coding user data is not security, but simplicity (add/modify/delete users without recompiling etc.) Storing passwords in plaintext is a problem, doesn't matter if they are in your program or in the ...


25

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


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


22

It is very common to do this. As you've noticed, there is a significant benefit for keeping code simple. If you do have an SQL injection vulnerability, an attacker can figure out your database structure using INFORMATION_SCHEMA. So hiding your database structure doesn't help you a great deal. Another concern in this area is Mass assignment vulnerabilities. ...


21

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


21

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


19

No, it's snake oil. When someone finds an SQL injection vulnerability in an application, then not knowing the table names is only a very minor hurdle. Many stock injection payloads (like the good old universal password ' OR '1' = '1) do not even need to know any table name. And if the attacker discovers a way to dump data from arbitrary tables, they just ...


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


18

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


18

The number of security measures in place and the capabilities to discover breaches will vary widely from company to company and depends on the type of data that is stolen. There are several ways a company will learn of a breach: security sofware catches unusal behaviour and marks it for later review (or stops it on the fly after part of the data ...


16

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


16

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 http://mysqlserverteam.com/...


15

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


15

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]--/ \-- [...


15

Great question! You are asking the right questions. Short answer. In most cases, escaping at the output side is the most important thing to do. The best solution is to use a web development framework (such as Google ctemplate) that provides context-dependent automatic escaping and automatic defenses against other injection attacks (like prepared ...


15

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

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



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