Tag Info

New answers tagged

0

Yes, you should obfuscate those IDs, since you're leaking information. If your application is perfectly secure, the only information (ab)users may learn is a guesstimate of the number of users through the use of something called the Doomsday Argument‡. If they learn the IDs of several users, they'll know who signed up first and can guess how far ...


2

I've created a few systems that either do or don't use the primary key (or other identifier) in the URL. Which we use is totally dependant on the harm-factor -- for instance, for a site that is data driven read only, we use the primary key in the URL; we don't care if someone goes through the products sequentially. For systems that have security ...


10

One easy way would be to use the method youtube and other websites use. This is hashids (http://hashids.org). With this method you can give links like: http://www.example.org/user/fce7db/edit while fce7db would equal to a number e.g.: 12 This has the advantage of performance in contrary to generating another random hash in the database, because you only ...


0

You don't provide enough information about the application to know whether you should obscure it or not. As such, this part of your question isn't answerable. However, if you have to ask, then the answer is probably yes, and even if it isn't then going above and beyond the call of duty provides more protection than the alternative. Rather than hiding or ...


4

No. One way or another, you need to identify the specific record with a unique identifier in the URL. That can be the primary key or something else. If you need to hide the order or sequence you can use a second column with a random and unique string like Z2wDKo0ubb1D2VngFh4N. If you want more security, use SSL. This doesn't prevent the user from seeing ...


21

The only piece of information that you could hope to "hide" is the sequence: since a database will allocate primary key values with a counter, people who see they key can make a guess as to when the corresponding user account was created. Apart from that, there is no other information that any obscuring scheme may actually hide. The attacker already knows ...


2

In this particular example there's very little you could do, even if you hadn't magic_quotes. That's because a SQL injection normally can only add to the query string. Since the string is an INSERT command, you can only INSERT something. In theory, if the SQL server behind supported "chained commands", you could transform a command in two: INSERT INTO ... ...


1

That SQL injection don’t work on your server may be due to magic quotes, which escape certain characters in incoming data with backslash escape sequences: […] all ' (single-quote), " (double quote), \ (backslash) and NULL characters are escaped with a backslash automatically. This is identical to what addslashes() does. These are exactly the characters ...


1

Could it? Yes. Is it? That's less certain. If your MySQL server is configured properly, it isn't accessible from the Internet at large, and the credentials are useless to anyone who doesn't have the ability to run code on the server. Of course, this assumes that the username and password are unique to the server.


5

Yes, of course is a potential security threat. MySQL can always have a vulnerability in it, perhaps something like CVE-2003-0150 MySQL Root Privilege Escalation Vulnerability from many years ago. New flaws can be introduced with any update, and old flaws can be discovered at any time. Just because you ask MySQL not to let the user run or create anything ...


3

Would I be risking anything on my side by doing so? yes. ... Even if the system is 'secure' (i.e. no priv esc vulnerabilities as the other guy correctly mentioned - you're making access easy for that kind of thing) they can DoS your system with expensive queries. I'd also make sure you definitely lock down all privileges to ruin fun like …’ UNION ...


0

Yes, You can write your shell onto the web server with SQL statements without logging into the admin panel or any other control panel. But for this you have to met certain requirements. 1.Your must have write privileges and a writable directory (where you have to upload your shell) 2.Root Path (i.e /var/www/website/) 3.Magic Qoutes must be enabled Now ...


0

I know I am three years late to the party, but I like to point out something I missed in the answers for those finding this in Google. Most "leaks" from hacked websites are the result of SQL Injection, and much less from a root-ed server where the hacker has full access to the raw database files. SQL injection is an attack technique where the hacker can ...


1

The blog post at Portcullis security seems to be saying that you have to hash the 12-byte "salt" with SHA1 to turn it into a 20-byte string before prepending it to the hashed password.



Top 50 recent answers are included