Hot answers tagged

8

TL;TR: these are not problems of the database. Maybe you are using a wrong architecture for your hidden service. And regarding the additional information after the edit of the question see at the end of this answer. What SQL database software should I use for the best security on my site? IE to prevent SQL injections and other vulnerabilities etc. ...


6

Any information about the internals of a system or application helps an attacker craft a specific attack. For instance, that error message includes table names, which means it becomes far easier to craft a SQLi attack. In addition, with detailed error messages, I could try to trigger different errors to map out the function of the backend, and even find ...


5

There's a big gap between "does not require" and "implemented by the lowest bidder". why do we even use full-power database software and SQL queries Because if you're already running a SQL database for your transactional data, implementing a second technology stack with appropriately trained development and support staff for a very specific function is ...


5

Using SQLMap will be helpuf, since it scan for most well-known vulnerabilities and will save you some time and efford. But, the greatest threat is a hackers' imagination and ability to exploit something more complex and unusual than SQLMap can find. For me, the best way to check for sql injection vulnerabilities - and even more types of vulnerabilities - is ...


2

Depends on the permissions given to the database user who you are acting as. If they have command execution privileges, it would be possible to use those to run a command such as id. Without that privilege, though, it is not supposed to be possible, but could be if the MySQL user was also a valid system user. In that case, it is possible to obtain the MySQL ...


2

[I]t seems to me that fuzzers can generate certain conditions that manual testing can't generate. No, they can't. The server does not know if an HTTP request originates from a fuzzer like ZAP, a browser or anything else as long as they send exactly the same HTTP request. The key words here are exactly the same. Since you don't know what is going on on ...


2

It does provide a security risk, though it may not be a huge one. What that shows is actual code, which reveals: The language your backend uses (at least I hope that's your backend code - if you're doing a database query on the client side, you'd be revealing far too much information to them), and possibly some of the libraries that you're using. ...


2

I think you are confusing two things: The code vulnerable to an SQL injection attack. The thing executing an SQL injection attack. The example page you link to has Java code of type #1, and uses the program SQLMap (written in Python) for type #2. You seem to be asking aboug type #2, but lets go through them one by one. #1 - The code vulnerable to the ...


1

usually a user table provides the relational association to content in the actual database. eg user:jon_smith posted this blog post The user table is also the logical place to store login credentials. The problem/question is not 'why is a database storing login credentials', but rather 'why arent people storing hashed values of passwords and comparing the ...


1

Another angle to symcbean's answer. The whole situation seems rather simplified. Who should take care of what can be queried and what can't? The underliyng DB (using special tables for user storage), the backend of the web application server or even a WAF? What about queries including LIKE statements (i.e. PasswordHash like 'a%', you can see where this is ...


1

I think you should check for SQL Injection vulnerabilities manually, because you have more probabilities to detect a vulnerability, also you adquire more experience as information security professional. On the other hand, it isn't good to trust tools like SQLMap; firstly, a tool doesn't have the experience and knowledge than a human has, a tool is limited to ...


1

It depends on the code of your application whether this input can be misused, not on the database or the query (disregarding parametrized queries). If your application rejects all but valid numbers, there is no possibility that the input can be misused, since only "harmless" numbers will be inserted into the query. If your application does no proper ...


1

Several things to keep in mind: The exploit has not been confirmed at exploit-db.com as stated by Michael in the comments. The server could be running a WAF that returns 200 OK headers to confuse SQLMap. The server could be running something that filters out "bad" characters in POST/GET request which in result voids the exploit. Try executing the exploit ...


1

Slick Scala code is vulnerable to SQLi when you use Slick with #$ to directly insert your literal into the SQL: NOT SAFE def slickInterpolationInsert(firstName: String, lastName: String, email: String, password: String) = db.withSession { implicit session: Session => sqlu"insert into users (first_name, last_name, email, password) values ...



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