In DB2-LUW SQL, I can write a query to do this:
select * from customers
&input
When a user runs that they'll be prompted for input and can type:
where name = 'Bill'
And the query that actually gets executed will be:
select * from customers
where name = 'Bill'
I am trying to figure out a way to vary the value of &input to alter the query based on more basic user input - so they won't need to type in where name = 'Bill'.
For example, the user could be prompted to enter either YesBill or NoBill and depending on what they've entered, the value of &input will be set and the executed query would be either:
select * from customers
where name = 'Bill'
or
select * from customers
where name <> 'Bill'
The example is meaningless, I'm mostly wondering if it's possible to vary the value of &input without forcing the user to type in SQL code.
Hope that makes sense. Thanks for any help!
The answer to this question really depends on the SQL client that you are using.
For example, if you use DBeaver, then you can simply use : to prefix your variable names and then when executing the query, you will get a prompt to window to enter your variable names.
Other query tools may, nor may not, provide a similar capability
Related
Suppose I have given such a table in sql
According to Gmail (which I have given in advance) I want to get the Username value.
For example, if "Gmail" would be "Gela1#gmail.com" I should get string - "Gela gela".
if "Gmail" would be "mamuka#gmail.com" I should get string - "Mamuka snaia".
How to do this?
You can easily make an SQL query like:
SELECT Username from tableName where Gmail = 'Gela1#gmail.com'
Replace tableName with your table name.
https://www.w3schools.com/sql/sql_select.asp
Is there any possibility to write delete query inside Where clause.
Example:
Select ID,Name From MyTable Where ID IN(Delete From MyTable)
It may be crazy, but let me explain my situation. In our reporting tool, we are supporting to enter SQL where query.
We will use our own Select and From Clause query and combine the user's where query input.
Example:
Select ID,Name From MyTable Where ("Query typed by user")
Here, user can type any kind of where query filter..
If he types like ID=100 our final query becomes like this
Select ID,Name From MyTable Where (ID=100)
One of our customer asked us what will happen if anyone type the delete query as where query filter. he feels this may be the security hole..so we have tried that kind of possibility in our dev environment. But the sql returns error for the following query.
Select ID,Name From MyTable Where ID IN(Delete From MyTable)
So finally, my question is, is there any other possibility to write Delete Query inside Where clause or Select clause.. If it possible, how can I restrict it?
Yes. They can run a delete. They can type:
1 = 1; DELETE FROM MY_TABLE;
Or even worse in some ways, (since you should have backups):
1 = 0 UNION SELECT SOCIAL_SECURITY_NUMBER, CREDIT_CARD_NUMBER, OTHER_SENSITIVE_DATA FROM MY_SENSITIVE_TABLE;
Now, in your case its hard to validate. Normally if you are just passing a value to filter on you can use parameterised sql to save yourself. You however also need to let the user select a column. In cases like these, usually we use a drop down to allow the user to select a predefined list of columns and then validate the column name server side. We give the user a text box to enter the value to match and then parameterise that.
It's not quite possible. But he can do something like this :
Select ID,Name From MyTable Where (ID=100); (DELETE FROM MyTable Where 1 = 1)
by using ID=100); (DELETE FROM MyTable Where 1 = 1 instead of ID=100
I believe what your customer is talking about is SQL injection, as long as you have taken appropriate methods to block other queries from running after your select statement is done, then you should have no problem in letting them type whatever it is that you want.
From my experience there is no way to delete anything when you are doing a select statement.
Just make sure you have query terminator characters so they don't write something like the following.
select column1,column2, from myTable where ID in (1,2); delete from my table
this would be a valid worry from your customer if you aren't taking proper steps to prevent sql injection from happening.
You could have your SQL reporting tool just not have update, or delete permission and just have it have Read permission. However, it is up to you guys have you handle your sql injection security.
Assuming ColdFusion 10,0,13,287689 and Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production.
With this example...
<cfquery name="q" datasource="ds">
update someTable set
#form.col#label = <cfqueryparam cfsqltype="cf_sql_varchar" value="#x#">
where id = <cfqueryparam cfsqltype="cf_sql_decimal" value="#id#">
</cfquery>
Also assuming there is no data validation checking on #form.col#, how could this be exploited? Obviously they could cause the query to fail with an invalid column, but I don't see any way something more malicious could be done since multiple statements cannot be ran in a single <cfquery>. So something like this does not work...
#form.col#:
id = 1; delete from users; --comment everything else out...
I'm aware that with SELECTs it's easier to exploit using unions to get data you're not authorized to see, but I'm curious about this specific update statement.
Whilst the traditional example for SQL injection involves sequential SQL statements, that is only a simple example used to highlight the issue - if unprotected user-derived text is allowed anywhere in any query there's a chance an attacker will be able to make use of it.
In this specific example, your query is:
update someTable
set #form.col#label = ?
where id = ?`
To abuse that is simple - prefix a genuine col value with something like:
public_column = (SELECT badly_encrypted_password
FROM users WHERE username='admin' ), <orig_value>
The resultant SQL is then:
update someTable
set public_column = ( SELECT badly_encrypted_password FROM users WHERE username='admin' )
, <orig_value>label = ?
where id = ?`
Which of course sets the value of that column to the result of the sub-query, and then a separate select in another area would then innocently return the sensitive data.
Alternatively, an attacker may decide simply to deface/remove data using this method, and depending on what precisely Oracle's SQL syntax allows, other things might be possible.
I'm building a query to run against a database by appending user entered data with some additional information like this:
SELECT * FROM vBranch WHERE (((BranchIsActive = 'Yes' AND BranchIsValid =
'Yes') AND BranchIsInternational = 'Yes' AND 1=2) AND
vBranch.BranchSecurityGroup=1).
This part:
SELECT * FROM vBranch WHERE ((
is appended by me,
and this part:
(BranchIsActive = 'Yes' AND BranchIsValid = 'Yes') AND BranchIsInternational
= 'Yes'
is the user entered value
and this part:
AND 1=2) AND vBranch.BranchSecurityGroup=1)
is also appended by me.
What my doubt is whether the user can write any query which excludes the string which i appended before and after the user entered data and execute only the data which the user entered against the database? Is it possible?
One thing to note is that i've restricted few DML and DDL statements too except the "select" statement since i'm building a "select" statement to execute against the database.
It doesn't matter what you have in front of your SQL statement. As long as you execute your sql as a dynamic statement it's a high candidate for SQL injection as already pointed by SWeko. You can try it out for yourself. Create a table named "DeleteMe". Then enter the following in your textbox: 1=1));DROP TABLE DeleteMe;--; Then check your database and see that DeleteMe table is gone.
Additionally, while this does not answer your question, I am concerned about the "1=2" in your query. It will almost certainly yields no result, hope that is just a "not good example".
I have the same copy of access running in 3 cities right now. They work perfectly ok. They are 99% the same with one minor difference. Each of them has two views which use different odbc connection to different cities DB (all these databases are SQL Server 2005). The views act as datasource for some two very simple queries.
However, while I tried to make a new copy for a new city, I found that one of the simple internal query returns the correct number of row but all data are empty while the other query functions correctly.
I checked the data of these two views, the data is correct.
The one causing problem are like
Select * from View_Top where Name = "ABC"
when the recordset returns, even rs!Name give me an empty string.
Please help
Well the query looks a little wrong to me, try using ' instead of " to delimit your ABC string...
Without the definition of VIEW_TOP it's hard to tell where your error is, but if you're getting rows but the columns are NULL I'm guessing that VIEW_TOP (or something it depends on) includes an OUTER JOIN and you're pulling the columns from the wrong side of the JOIN.
SELECT
acc.FIRM,
acc.OFFICE,
acc.ACCOUNT,
a.CONV_CODE,
a.OTHER_AMT AS AMOUNT,
a.TRANS_DATE,
a.DESCRIPTN,
a.JRNAL_TYPE
FROM AccTrans AS a LEFT OUTER JOIN ACC AS acc ON a.ACCNT_CODE = acc.ACCNT_CODE
WHERE
(acc.SUN_DB = 'IF1') AND
(ANAL_T0 <> '') AND
(a.TRANS_DATE < '20091022') AND
(a.JRNAL_TYPE = 'MATCH');
This is the definition of the view. Indeed, in Access i am able to view the result of this query, it has data. that's why i know the recordset returns the correct number of row (by counting the loop in the code). sorry for my mistakes, i use Account in the where clause, the select statements should be like
select Firm, Office, Account, Trans_Date.... from
view_top
where account = 'ABC'
the query returns the right number of row but all row data (even the account field) are empty string.
then i found out what really cause the problem is the AMOUNT field, if i omit the amount, everything works. though i don't understand why.
view_top definition
"Name, Account, AccountCode, Amount, Date...."
Select Statements:
Select Name, Account, AccountCode, Amount, Date
From View_Top Where Name = 'xxx'
I found that if I omit the Amount, everything works.
Though I still don't understand why.