I'm having problems with my query returning errors. What I have at this moment is this:
comi C X'7D'
SqlQuery S 500A
VarSel S 10A
VarSel = *blanks;
SqlQuery = 'select USU into VarSel from FXXUSELN ' +
'where USU = upper(' + comi + %trim(pusuario) +
comi + ') and PWDUSU = upper(' + comi +
%trim(ppassword) + comi + ')';
Exec SQL execute immediate :SqlQuery;
psqlcod = sqlcod;
But when I try to debug that code, it returns -084: UNACCEPTABLE SQL STATEMENT as sqlcod. Printing the SqlQuery variable in the debugger call I get this string, which seems to be correct:
select USU into VarSel from FXXUSELN where USU = upper('usua
rio') and PWDUSU = upper('password')
Anybody knows how to solve this problem so I can make a login stored procedure? Thanks in advance.
The problem is that SELECT INTO can not be dynamically prepared.
If you look at the Invocation section of SELECT INTO in the manual you'll see:
This statement can only be embedded in an application program. It is an executable statement that cannot be dynamically prepared. It must not be specified in REXX.
Also note the following Actions Allowed on SQL Statements section of appendix B in the manual which summarizes where/how each statement may be used.
Finally, if what you tried had worked, you'd have opened yourself up to SQL Injection attacks. Generally speaking, for any DB you should avoid dynamic SQL. If you must use dynamic SQL, then you should use parameter makers instead of directly concatenating user input into the string.
In your case, there's no need for dynamic SQL if the first place. Static SQL is easier, safer, and allows the use of SELECT INTO
exec SQL
select USU into :VarSel from FXXUSELN
where USU = upper(:pusuario)
and PWDUSU = upper(:ppassword);
Related
Long time lurker and learner, first time question here. I'm working a project for a local library to pull some data from their database to help the employees pull books put on hold for patrons. The catch here is the access to the database is read only. I cannot create any temporary tables or views.
We've created a long query to generate the data needed, I used a couple CTEs to whittle things down and then there's some logic based on which location the book may reside in to show where it should pick from. All in all, we're happy with the query results.
When I try to implement it using jdbcTemplate, I can't seem to find a way to get anything other than SELECT * to work.
WITH holdCTE1 (holdID, itemID, ...) AS (
SELECT *
FROM
table 1,
table 2,
table 3
WHERE
yada yada
This will give me results if I then do a SELECT * FROM holdCTE1.
If instead I specify columns, like this
WITH holdCTE1 (holdID, itemID, ...) AS (
SELECT t1.holdID, t2.itemID, t3.title
FROM
table 1,
table 2,
table 3
WHERE
yada yada
I get a syntax error at the first from table, regardless. I've tried adjusting all my table JOINs and using aliases and just about everything I can come across, but it doesn't seem to help.
A couple of things we're using to help the filtering and such, since we can't create a view to make it easy, is to call out the subqueries, so for example, in CTE1 we add a final column
'bib hold' AS hold_type
Even with the SELECT *, 'bib hold AS hold_type, I get the same syntax error. The actual wording of the error is:
StatementCallback; bad SQL grammar ... then my query ... nested exception is org.postgresql.util.PSQLException: ERROR: syntax error at or near ... the first thing under the FROM line
The library is using a Postgresql database, and I'm using Spring with jdbcTemplate for the SQL side.
Thanks in advance for looking.
Sorry for the poorly worded question, but I think I stumbled across an answer this evening. I was checking all of my queries I'd noted in pgAdmin, and I did a copy/paste into my java class.
With the escape characters, the code seems to run just fine. So this looks like it is passing info correctly to the query
WITH hold_bib (hold_id, item_id, birl_bib, patron, status, hold_type) AS (SELECT\n"
+ " h.id,\n"
+ " i.record_id,\n"
+ " birl.bib_record_id,\n"
+ " h.patron_record_id,\n"
+ " i.item_status_code,\n"
+ " 'bib'AS hold_type\n"
The function looks like this at the beginning now:
public List<Hold> libraryNotPicked() {
String sql = "\n"
+ "WITH hold_bib (hold_id, item_id, birl_bib, patron, status, hold_type) AS (SELECT\n"
+ " h.id,\n"
+ " i.record_id,\n"
+ " birl.bib_record_id,\n"
+ " h.patron_record_id,\n"
+ " i.item_status_code,\n"
+ " 'bib'AS hold_type\n"
...
+ " ;
List<Hold> holds = jdbcTemplate.query(sql, new BeanPropertyRowMapper<>(Hold.class));
return holds;
Seems to me the key is the \n type characters in the query.
A line of code like
my $sql_query = "SELECT * FROM Users WHERE user='$user';";
might introduce an SQL injection vulnerability into your program. To avoid this one could use something like
my $sth = $dbh->prepare("SELECT * FROM Users WHERE user='?';");
$dbh->execute($user);
However, in the code I am currently working on the following is used
$sql_query = "SELECT * FROM Users WHERE user='" . $user . "';";
$dbh->prepare($sql_query);
$dbh->execute();
Does this actually work? If yes, are there any differences to what I would have done? What are the advantages and disadvantages?
my $sth = $dbh->prepare("SELECT * FROM Users WHERE user='?'");
This won't work because it's searching for a literal '?' character — not a parameter. If you try to send a value for the parameter, MySQL will be like, "what do you want me to do with this?" because the query has no parameter placeholder.
If you want to use a parameter, you must NOT put the parameter placeholder inside string delimiters in the SQL query, even if the parameter will take string or datetime value:
my $sth = $dbh->prepare("SELECT * FROM Users WHERE user=?");
The next example:
$sql_query = "SELECT * FROM Users WHERE user='" . $user . "'";
$dbh->prepare($sql_query);
$dbh->execute();
That will run the query, but it's NOT safe. You can prepare any query even if it has no parameters.
Using prepare() is not what makes queries safe from SQL injection. What makes it safer is using parameters to combine dynamic values instead of doing string-concatenation like you're doing in this example.
But using parameters does require the use of prepare().
PS: You don't need to put ; at the end of your SQL queries when you run them one at a time programmatically. The separator is only needed if you run multiple queries, like in an SQL script, or in a stored procedure. In your examples, the ; is harmless but MySQL doesn't require it, and it will just ignore it.
MySQLdb: cursor.query( 'select * from %s;', ('thistable',) )
should end up as: 'select * from thistable'
actually ends up as: "select * from 'thistable' "
the db natually throws syntax error: ...near ' 'thistable' ' at ...
It behaves as though the data converter is including the string's quotes as part of the string, ie the string is " 'thistable' " instead of 'thistable'. Any and all help with this is deeply appreciated. One thing I did notice in my questing is that the script's charset is utf8, while the db server and db are latin1. Could this be my problem?
OS: os X Sierra
python: 3.6
MySQL: 5.3.6
mysql-connector-c: 6.1.11
There's a difference between building dynamic SQL and building parameterized queries.
In general, parameterized queries let you plug in values for comparison/input, but not database objects. So, your application code assumes that %s is a quoted literal, not an database object.
If you need to dynamically add in database objects (tables, columns, procedure names, etc.), you will probably need to build the query string first, with placeholders (like %s) for actual parameters you need to pass in.
In this case, ypercubeᵀᴹ's suggestion to simply use the string 'select * from thistable' directly. If you needed to run the same query against multiple tables, loop through the list of table, building the string like:
queryString = 'SELECT * FROM ' + currTable
I am doing a project for my school and I am task to debug all of the issues found using the application call HPE Fortify. The report generated by the application only indicates the code below prone to SQL injection:
String sql = " select Distinct p1.desc1,p2.desc2 from parameter p1"
+" inner join parameter p2"
+" on p1.ParaCode1='CR_DERIVE' and p1.ParaCode2=p2.Desc2"
+" inner join parameter p3"
+ " on p2.ParaCode3=p3.ParaCode1 and p3.ParaCode3=p2.Desc2"
+" where p2.paracode1='ATTRIBUTE'"
+ " and p2.ParaCode2='" + ddl_attribute.SelectedValue + "'";
But not the codes below:
strSQL = "SELECT Paracode2 FROM Parameter WHERE Paracode1 = 'PROGMGR' AND Desc1 = '" + login + "' AND Status = 'A' ";
I would like to know the reason why as I am unclear regarding SQL injection and I am new to this. Thanks for the response
You're concatenating some application variables into your SQL query string, so the safety depends on how those variables' values were set. Did they come from some untrusted input? Or were they set from some safe application data?
If HPE Fortify has analyzed your code and knows how your login variable was assigned its value, it may be able to tell that it's safe to use in an SQL expression. Whereas it may not be able to make that conclusion about the SelectedValue variable, so it assumes it's unsafe and therefore could cause an SQL vulnerability.
The Perl language does something similar, without the use of a tool like HPE Fortify. Every Perl variable is either "tainted" or "untainted" depending on where it got its value. So you can tell whether a variable is safe to use in SQL, or in eval() or other possible code-injection situations. It's a pity more languages don't support something similar.
But I agree with other commenters that you should learn to use query parameters. It's easy and it's safe. And you can stop getting eyestrain figuring out if you've balanced your quotes-within-quotes correctly.
Your code sample looks like it might be Java. Here's an example in Java:
strSQL = "SELECT Paracode2 FROM Parameter"
+ " WHERE Paracode1 = 'PROGMGR' AND Desc1 = ? AND Status = 'A' ";
Notice the ? placeholder for the parameter has no single-quotes around it within the SQL string. You must not put SQL quotes around the placeholder.
PreparedStatement stmt = con.PreparedStatement(sql);
stmt.setString(1, login);
ResultSet rs = stmt.executeQuery();
For more information to help you understand SQL injection, you might like my presentation SQL Injection Myths and Fallacies, or the video of me delivering that talk: https://www.youtube.com/watch?v=VldxqTejybk
I am considering using RCP to run a generic datastage job, but the initial SQL changes each time it's called. Is there a process in which I can use a User Activity Variable to inject SQL from a text file or something so I can use the same datastage?
I know this Routine can read a file to look up parameters:
Routine = ‘ReadFile’
vFileName = Arg1
vArray = ”
vCounter = 0
OPENSEQ vFileName to vFileHandle
Else Call DSLogFatal(“Error opening file list: “:vFileName,Routine)
Loop
While READSEQ vLine FROM vFileHandle
vCounter = vCounter + 1
vArray = Fields(vLine,’,’,1)
vArray = Fields(vLine,’,’,2)
vArray = Fields(vLine,’,’,3)
Repeat
CLOSESEQ vFileHandle
Ans = vArray
Return Ans
But does that mean I just store the SQL in one Single line, even if it's long?
Thanks.
Why not just have the SQL within the routine itself and propagate parameters?
I have multiple queries within a single routine that does just that (one for source and one for AfterSQL statement)
This is an example and apologies I'm answering this on my mobile!
InputCol=Trim(pTableName)
If InputCol='Table1' then column='Day'
If InputCol='Table2' then column='Quarter, Day'
SQLCode = ' Select Year, Month, '
SQLCode := column:", Time, "
SQLCode := " to_date(current_timestamp, 'YYYY-MM-DD HH24:MI:SS'), "
SQLCode := \ "This is example text as output" \
SQLCode := "From DATE_TABLE"
crt SQLCode
I've used the multiple encapsulations in the example above, when passing out to a parameter make sure you check the ', " have either been escaped or are displaying correctly
Again, apologies for the quality but I hope it gives you some ideas!
You can give this a try
As you mentioned ,maintain the SQL in a file ( again , if the SQL keeps changing , you need to build a logic to automate populating the new SQL)
In the Datastage Sequencer , use a Execute Command Activity to open the SQL file
eg : cat /home/bk/query.sql
In the job activity which calls your generic job . you should map the command output of your EC activity to a job parameter
so if EC activity name is exec_query , then the job parameter will be
exec_query.$CommandOuput
When you run the sequence , your query will flow from
SQL file --> EC activity-->Parameter in Job activity-->DB stage( query parameterised)
Has you thinked to invoke a shellscript who connect to database and execute the SQL script from the sequential job? You could use sqlplus to connect in the shellscript and read the file with the SQL and use it. To execute the shellscript from the sequential job use a ExecCommand Stage (sh, ./, ...), it depends from the interpreter.
Other way to solve this, depends of the modification degree of your SQL; you could invoke a routine base who handle the parameters and invokes your parallel job.
The principal problem that I think you could have, is the limit of the long of the variable where you could store the parameter.
Tell me what option you choose and I could help you more.