In class we're now learning about SQL injection attacks and my professor showed us examples where we either use only the username input for the attack, or both the username and password.
I started reading about SQL injection more and found that you can create attacks by typing 'admin' or 'xx' into the username input and then primarily using the password input for the attack.
My question is, is it possible to perform a SQL injection attack using only the password input and typing nothing in the username input?
EDIT: This question is in the context of using a SQL injection attack on a database via the password box of a login page of a website.
is it possible to perform a SQL injection attack using only the password input and typing nothing in the username input?
Yes.
If you're asking this, then your professor failed with explanation. He's not alone, though.
Most people in the world do confuse the injection and the exploit. Taking one for the another.
What your professor demonstrated to you was exploit. Yes, various particular exploits involve various particular query parts. But the principle of injection is breaking of the query integrity. That's all. As long as you can inject any code into query, it is vulnerable. Will you be able to exploit it or not - that's another matter, one have to learn SQL, not injections for this.
But the point of injection is just breaking of query integrity. And for this matter it doesn't matter, be it password or "remember me" checkbox. Comprehensible?
For the better understanding I'll recommend you an article, I wrote aiming protection from injections, but it surely can help you to understand the injection too. The first three chapters and appendices could be of the most help. Here it goes: The Hitchhiker's Guide to SQL Injection protection
Yes it's possible depends on how code is written to validate . If code is written only to get a true/false result set. You can very much anything to get a true result and get into application . For example select '1' from xyz where username='xxx' or yy=yy
Related
I am just reading up about mysql injection and I wanted to confirm that if you force a user to use list options for their input that is written to mysql (and those inputs are set as readonly) is the system essentially secure from mysql injection? would one need to put in measures to protect malicious mysql injection attempts for sites developed this way?
If I understand you correct then no.
You can try to force the user but everything that the user enters, happens on the client side. Since this is on the clients side and the client has absolute control over the webpage he can manipulate it to whatever he wants or even genereate own POST or GET Requests regardless of the page he received.
There are some tools that can achieve this goal.
If you want to secure your database against SQL Injection I recommend that you use prepared statements only (How can I prevent SQL injection in PHP?)
Any countermeasures that you take have to be implemented on the server side. You should always expect that the user sends whatever will break your code and do harm to you, regardless of the "restrictions" he has to his input.
Based on the information provided in the question:
Q: ... is the system essentially secure from mysql injection?
A: No, this doesn't guarantee that the system won't be vulnerable to SQL Injection.
Q: would one need to put in measures to protect malicious mysql injection attempts for sites developed this way?
A: The best measures against a malicious attacker exploiting a SQL Injection vulnerability is to prevent SQL Injection vulnerabilities in the first place.
And that means speicific coding patterns for the database interactions: prepared statements with bind placeholders. Or, at a minimum, properly escaping all potentially unsafe values that are included in the text of a SQL statement.
Your web page can have a drop down list box from which the user makes a choice, and your web page can do validation in Javascript. But that doesn't prevent a malicious attacker from bypassing that, and sending a request that doesn't conform the javascript validation.
The script on the server that handles the request will need to perform the validation... probably the same validation that was done in javascript on the web page that generated the request.
But any database interactions will also need to follow the normal patterns that prevent SQL Injection vulnerabilities (i.e. prepared statements with bind placeholders, or at a minimum, properly escaping potentially unsafe values.)
Multiple lines of defense.
It's not at all clear what you've been reading.
As a starting point, I recommend you review the information available from the OWASP project.
https://www.owasp.org/index.php/SQL_Injection
This isn't the be-all-end-all, but it's a good overview. If you are in a hurry, you can look at the SQL Injection Prevention Cheat Sheet.
What are php input attack,and how to protect from input attack
i allow user to enter data from 11 input field
i need to know php attacks and how can i protect from attack can someone give me idea about php attack's
a how can i protect from user input do i need to create php function are and validate function using jquery
can someone give me idea attacks and prevention
user input are saved to sql after processing
PHP-specific bugs aren't really a huge issue. What you should worry about are generic input-poisoning attacks.
These include:
SQL Injection
XSS
Shell script escaping
There are probably others that I've forgotten, but that's where you should start. I would also advise asking more specific questions. Asking simply about security in PHP is much too broad of a subject.
A good resource for PHP security however would be OWASP
i read it some where in form that xss clean in codeigniter dosn't not prevent in sql injection and it should not be used in input but it should be used in output it is true... Please can any one explain.. then how to prevent from sql injection in codeigniter.
Thank you for replaying me..
and sorry for the bad english..
First of all, both topics are not specific to CodeIgniter.
But CodeIgniter has specific way to handle some of this. Please read https://ellislab.com/codeigniter/user-guide/general/security.html
Remember that CodeIgniter will not save you from any of these and you must understand how both of these attacks works.
It is important to understand these are two different attacks, as with any attacks, they could be coupled together. For example using a XSS/CSRF to perform a SQL injection via. a crafted link to a administrator or etc.
XSS is when the attacker can inject code to be executed on the clientside. For example placing a <script> tag in your code. This often happens if you output data which the user has provided without sanitizing it or validating it. Typically this could be their username, a post title, $_GET data and etc. There are alot more ways to get a script executed on the clientside other than a script tag, so make sure to read up on the subject.
To avoid it, always escape user inputted data, from any source.
You can read more about it https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29
SQL injection is when the attacker can change the SQL query for a malicious purpose. The most common way to avoid injection is to make sure to escape every input, before passing it to a query. Using prepared statement also helps alot. In CodeIgniter, you often use the "ActiveRecord" db thing, which escapes the input for you.
You can read more about it, including examples https://www.owasp.org/index.php/SQL_Injection
You should also read https://www.owasp.org/index.php/Top_10_2013-Top_10 and become familiar with the most common attacks.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to prevent SQL injection?
This is more of a philosophical point i'm trying to determine, out of curiosity.
I know that theoretically, any password or encryption is crackable.
But is it the same with SQL injection, where one just has to find the appropriate measures to deal with /bypass whatever security measures are implemented in the site? Or is injection something that can be definitively and with certainty defended against using a fixed set of security measures?
Im essentially wondering if it is possible to the input fields in my site unhackable through injection, or whether there will always be some vulnerability?
Being vulnerable to SQL injection is a bug. A well-built application will not contain such a bug, and no amount of effort will make such a bug appear.
SQL injection implies the data entered conforms to valid SQL (though typically injected in a creative way to produce undesired results).
To protect against it, you simply need to ensure that any user supplied data is encoded in a way that it cannot be misused.
As mentioned in a link above ( How can I prevent SQL injection in PHP? ), using prepared statements is a best practice to protect against SQL injection.
Sql injection is a technique used to hijack the security of website.
Sql injection occurs when data specified in input fields are not filtered for escape characters and passed into sql query for execution.
For testing sql injection please refer the following url.
http://sqlzoo.net/hack/
In above url try specifying "'" in field for name and specify "OR 1=1 #" in field for password
So the resultant query will be
SELECT * from user where name='' OR 1=1#' and password='';
In the above example you can notice that query is broken after specifying above data in input fields and any anonymous user can easily login into website.
There are several techniques to prevent sql injection.
(1) Input data must be filtered using mysql_real_escape_string while being passed into sql query for execution.
For more details about mysql_real_escape_string function please refer the documentation mentioned in below url.
http://php.net/manual/en/function.mysql-real-escape-string.php
I'm not some kind of hax0r or so, but my boss has a website and I told him that it was vulnerable to sql injection attacks. He then responded that it was not a danger, because all the information is public; so I told him that there is the possibility to drop the tables.
Usually the DROP table command works, can someone tell me why not in this case?
NOTE: THIS DATABASE ONLY STORES NEWS, NOT VITAL INFO!
news.php?id=-99%20union%20all%20select%201,2,3,4,5%20from%20information_schema.columns%20where%20table_schema=0x656e6469616d615--
Please, do not reply with hax0r-hate comments, if I wanted to know how to hack I would be on irc channels, not here.
EDIT:
If he's safe from database editing I think he's right.
He could disclose the sql query but that would defeat the purpose of showing him the danger is real.
If you are able to detect columns names from SQL injections, it means it is violatable.
It also means you could easily brute force attack a webpage and detect all the structure, users, export the data, etc... So yeah, site IS vulnerable and it goes much farther than "My data is public so i don't care"...
The hacker could find a way to insert data into the database, create some phishing, steal data from XSS attacks that he inserts into the database. There are tons of reasons to take this seriously. SQL injection doesn't mean that the hacker can only read your data, it can lead to serious compromises...
I'd count any disclosure of information as dangerous - if this doesn't get fixed now, what happens in the future when/if more sensitive information is placed onto that database? What if existing data is modified in a malicious fashion?
SQL Injection is very easy to protect against, and if you know of a possible vulnerability it should be fixed ASAP, regardless of what is deemed sensitive. Just my 2c.
SQL injection isn't a problem if the SQL user only has access to the SELECT privilege. Any other privileges could probably be a security threat (Particullarly DROP, but also INSERT or DELETE).
Personally, I would just protect it all against SQL injection, and then apply privilleges to the SQL user that restrict the ability to perform an attack even if my front line of defences is broken.
Even if the data is not sensitive, SQL injection could lead to phishing attacks, scams, and illegal content being displayed on the vulnerable website. Not good.