Questions about this topic? Sign up to ask in the talk tab.
Difference between revisions of "SQL injection/Cause"
From NetSec
(Created page with "<noinclude>{{subpage|SQL injection}}</noinclude> :<i>Now is a good time for orientation with SQL servers and queries with the SQL primer, otherwise this ...") |
|||
| (2 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | <noinclude> | + | <noinclude>:<font size="-2">[[SQL injection]] > Cause</font></noinclude> |
| − | + | <i>Now is a good time for orientation with [[SQL]] servers and queries with the [[SQL Orientation|SQL primer]], otherwise this text may prove be confusing. </i> | |
| − | + | ||
'''SQL Injection''' occurs when [[input]] from a user is directly passed to a [[SQL]] query by an [[application]]. In the context of [[Web applications|web applications]], user input comes from [[Web_Exploitation#Attack_Vectors|HTTP input]]. | '''SQL Injection''' occurs when [[input]] from a user is directly passed to a [[SQL]] query by an [[application]]. In the context of [[Web applications|web applications]], user input comes from [[Web_Exploitation#Attack_Vectors|HTTP input]]. | ||
Latest revision as of 02:33, 19 July 2012
- SQL injection > Cause
Now is a good time for orientation with SQL servers and queries with the SQL primer, otherwise this text may prove be confusing. SQL Injection occurs when input from a user is directly passed to a SQL query by an application. In the context of web applications, user input comes from HTTP input.
- Un-sanitized user input - The developer made no effort to stop an injection attack
- Improper type handling - An integer sanitized or otherwise treated as a string, or vice versa
- Lack of output filtering - Output from a query that had user input passed to it is used as input in later queries when rendering the page
- Cookies and other "hidden" forms of communication in the HTTP request header are also processed as user input and can be considered attack vectors as well.
