I'm learning about SQL Injection. And sometime I read in some document that we have to use unhex(hex()) function when exploit in URL address.
And my question is, why we have to use it?
First off, it cannot help you with SQL injection. If SQL injection is impossible, then no hex/unhex/whatever function will make it possible.
It can only help to exploit an existing SQL injection, when a site is protected by a very silly protection method like a black list disallowing a single quote in the input. So these functions can help to avoid using a quote or any other "malicious word" that may alert the filter.
But honestly, I cannot imagine a developer in 2018 using a black list filterig against SQL injection instead of prepared statements for the data/a white list for the everything else
Related
In terms of SQL injection, I understand why parameterizing a string parameter is important. But is it acceptable or justified to not parameterize a command when working with let's say a database dependent software for a company which is primarily targeted on internal use rather than that of external influence?
Like I always say, you need it not for Bobby Tables but for Sarah O'Hara. It is syntactically correct SQL query what you have from the prepared statement in the first place, while protection is just a side effect. It's the destination that matters. You have to mind the SQL query where your data goes into. While the data source should the last thing to consider.
Besides, I don't see a point in bargaining. What you're trying to buy for yourself here? Are parameters that hard for you? Well, blame the library you are using. A properly implemented a parametrized query is a simplest way to run a query.
I am a noob when it comes to understanding some of the attacks in SQL injection. I am currently seeing this attack in my log and was wondering if anyone can help me understand what it means
SQL Injection:
410'union/**/select/**/1/**/from/**/(select/**/count(*),concat(floor(rand(0)*2),0x3a,(select/**/concat(user,0x3a,password)/**/from/**/pwn_base_admin/**/limit/**/0,1),0x3a)a/**/from/**/information_schema.tables/**/group/**/by/**/a)b/**/where'1'='1.
Dont understand this completely, but the select concat(user,0x3a,password) from pwn_base_admin clearly tries to get a concatenated string of user names and passwords, divided by a ":"
The concat(floor(rand(0)*2),0x3a,( roughly does the same... the result would be something like 1:aUserName:UsersPassword.
If you need further help please give some more details (RDBMS, the part before the "union"...)
Hope this helps
Someone is actively trying to gain unauthorized access to your system - they're hacking in.
I don't know how critical this system is, but if it is of any importance, you should probably take the system offline until you sort out the database access part of the code. The first place to look for solutions is using bind parameters instead of string concatenation for your sql queries.
There are many resources available that describe how to use bind variables for whatever RDBMS you're using, but here is one article I found to get you started:
http://use-the-index-luke.com/sql/where-clause/bind-parameters
What is an example of an SQL injection attack for compromising the database?
What classes of SQL injection attacks cannot be prevented by the use of bind variables and why not?
How do bind variables help in preventing SQL injection attacks?
http://xkcd.com/327/
Speaking of native prepared statements - all the query literals which aren't supported (i.e. everything but simple strings and numbers) are obviously vulnerable, when not hardcoded.
https://stackoverflow.com/a/8265319/285587
1.:
Here's an example from the real world:
https://find-and-update.company-information.service.gov.uk/company/10542519
Since the company is still listed the attack seems to be unsuccessful as yet, however, in the case the injection succeeds in the future, I'll also include a screenshot.
Typically I use integer ids in my application, but for this one piece of dev I am doing look ups on a text field - a tag name.
I do make use of cfqueryparam but considering that it's a text field, could it be vulnerable to sql injection attacks, and if so, how do other people get around this other than tediously searching the string for SQL commands.
My query looks something like:
SELECT tagId -- etc etc
FROM tag
WHERE tagName = <cfqueryparam cfsqltype="cf_sql_varchar" maxlength="50" value="#arguments.tagName#" />
Thanks
That's safe by virtue of the fact that you're using <cfqueryparam>. That's what the tag does. It sends the value as text (or whatever the cfsqltype happens to be), not a command to be executed.
For the most part yes... doing sql injection for this would be very difficult. CFQUERYPARAM does make it almost impossible to sql inject a query. However, remember that nothing is 100% effective against all forms of attacks.
If you did not use cfqueryparam, then you would be vulnerable.
By using cfqueryparam you don't need to worry about SQL injection.
Try putting in injection attacks and see for yourself.
I've heard somewhere that using cfqueryparam together with Portcullis would be a stronger protection against XSS and block malicious hack attempts.
Most ColdFusion web developers are now finally using cfqueryparam, it
has taken about 10 years since that tag was introduced but I guess
better late than never. Keep in mind, that cfqueryparam prevents most
forms of SQL injection but not all. It also does nothing to cross-site
scripting (XSS) attacks. It doesn't matter how small your site is or
where it's hosted, it will experience these attack vectors. Portcullis
takes maybe 5 minutes to install and configure. Nothing is perfect,
but Portcullis has a solid track record - just google it. So, there's
simply no reason I can think of where a ColdFusion based site
shouldn't use it.
http://www.codfusion.com/blog/post.cfm/portcullis-2-0-released
Also, you may want to watch CFMeetup: Warning, your site is under attack presented by John Mason, the author of Portcullis.
I'm having a problem using $wbdb. When I insert or update data using $wpdb->insert or $wpdb->update, the SQL injection protection actually inserts the \' into the database, and when outputting that information it has the SQL escape with it. (ie: My Value\'s Escaped).
I know there's gotta be a way to escape this using a wordpress function, but I haven't been able to find it searching google and the wordpress codex. ...So what's that function, or what am I doing wrong (seems like the '\' shouldn't really get to the database in the first place) Thanks!
It looks as if magic_quotes are enabled on the server you are using.
There are a number of SO questions and answers that deal with what they are, why they're bad, and how to get rid of them, so I won't explicitly explain here, but suggest you look at a few of the following:
Magic quotes in PHP
Work around magic quotes, or just make sure they're off?
How can I disable PHP magic quotes at runtime?
How to turn off magic quotes on shared hosting?
PHP protecting itself from SQL injections?