New answers tagged

0

Separating these out may make your system much harder to attack. For example, say there's a SQL injection flaw on your website. The attacker may be able to use SELECT INTO OUTFILE to write a shell to your system. e.g. http://192.0.2.42/comment.php?id=738 union all select 1,2,3,4,"<?php echo shell_exec($_GET['cmd']);?>",6 into OUTFILE 'c:/xampp/...


1

In general, I agree with your implication that if you only have a single web application there is little security benefit to moving the DB onto a separate server. That being said, there could be some contrived scenarios where there might be a security benefit. For example, if the web application does not have full admin rights to the DB, then a compromised ...


0

Performance and scalability is enhanced by deploying it on two servers. I can imagine someone making configuration errors and opening up more ports on the database server. Due to the presence of the firewall this will not lead to a vulnerability easily.


1

I think that the other answers are wrong or at best impractical. In order to protect data in the database and have it accessible only by user request we can do the following. Upon registration of the user we generate two hashes. Hash A: Our password, bcrypt hash, stored in the DB Hash B: Our encryption key, not the same password hash, not stored anywhere ...


1

Those credentials have to be placed somewhere. If you decide to place them at a place like /usr/lib/cgi-bin, you'd have to grant your web user access to that directory structure which would in turn make your system more vulnerable. It is more common to place them one level above the web root as a compromise between the two. This way you don't open much of ...


3

However if you took that search string update aTable set someColumn='JackedUpValue' where someColumn like and performed the operation shown in this question, wouldn't you get updateaTablesetsomeColumn='JackedUpValue'wheresomeColumnlike which should not execute, right? As others have pointed out there are other ways of getting whitespace into ...


13

No. Let's say you have this as your SQL: "select * from people where last_name = '" + surname + "'" If I enter: 'OR(1=1)OR'a'=' into the input it turns into: select * from people where last_name = ''OR(1=1)OR'a'='' Which executes in Oracle and MySQL (at least) and returns all the rows from the table.


18

It would limit the problem, but not eliminate it. Consider the following situation: $un = str_replace(" ", "", $_POST["username"]); $pw = hash($_POST["password"]; $sql = "SELECT * FROM users WHERE username = '$un' AND password = '$pw'"; Lets say I post the username admin'--. That would log me in as admin, without using a single space. As wireghoul points ...


108

No. Removing spaces would not prevent SQL injection, as there are many other ways to make the parser process your input. Lets look at an example. Imagine that you had a url which used user supplied input unsafely in a query: http://example/index.php?id=1 => SELECT * from page where id = 1 In your example the attacker would use spaces: http://example/index....


46

We're in 2016! SQL injections are a thing of the past unless you use insecure code. Whatever language you use, if you want to prevent any and all SQL injections, use prepared statements or any other type of data binding. Prepared statements separate the query from the data, making it impossible for the data to affect the query. To directly answer your ...


0

You could consider FDE (full disk encryption) of the [ server | SAN | NAS ] that the data is resting on. If it's a Windows server, consider BitLocker: https://technet.microsoft.com/en-us/library/cc732774(v=ws.11).aspx


1

I suggest a more proactive approach as well by doing your own penetration testing against a non-production server setup specifically for this sort of thing. We use BurpSuite's scanner feature to test our own products - it has really helped augment our quest to find vulnerabilities. ZAP is a free alternative I've heard good things about, but have not ...


0

Given that you say this is not a real application, I'll only comment on a couple of points here. The first is an implementation detail that you might have already considered, the second is more of a theoretical "is this worth while?" question. 1. Password changes. It is generally considered good practice to require users to change their password every so ...


0

They could easily substitute the actual table and column names with aliases. However, from a security perspective, even a completely unredacted SQL query is unlikely to release any information that would be useful to an attacker. Once an attacker gains dba level access to the database, querying the schema is trivial. The reverse is not true.


1

Generally when you are trying to secure an application you want to make sure that you aren't disclosing any information that could potentially be used as part of an attack. This is the same reason that it is more secure to display a generic error page instead of a stack trace. Even though seeing the stack trace probably isn't a vulnerability itself - it ...


0

Maybe would be better to just ask the agency "How the data was filtered and precisely how the agency defined each category?" While I agree that hiding SQL to add security is just "security by obscurity", I also fail to see why providing the SQL queries would be the best way to provide the information you need or claim to need.


1

Firstly, on HTTP there is no way to do this securely. And when you include a TLS connection (a.k.a. HTTPS), why decrypt at the browser? That sounds as possibly the worst place to do so. If confidentiality is really that needed use proper encryption technologies like PGP/GPG and have the user decrypt / encrypt that on his/her/it machine. All you do is ...


0

In short, they aren't, and can't. What they are probably doing is processing several electronic credit transactions. On a credit card, you can max it out (problem if the card doesn't have a hard-limit but has a soft-limit that you can go above and pay down to the soft-limit on your next bill,) and it'll prohibit further transactions, and since the funds are ...


3

This is the job of a host-based firewall. While IP based rules are so integral to the system that the built~in GNU/Linux Firewall is named Iptables and the basic slement of a firewall is a list of rules (called a chain) that could easily handle whatever packets of the type you describe that aren't handled back at the hardware router/firewall ip layer, I have ...


0

The pgsql-brute script performs password guessing (brute-forcing) against PostgreSQL databases. It does not retrieve any version information or display anything but successfully-guessed usernames and passwords. A more useful command for getting information from a PostgreSQL database would be: nmap -p 5432 -sV myhost This performs service and application ...



Top 50 recent answers are included