According to recommendation of CWE-89, my function below has been parameterized, but Veracode still reports that CWE-89 is available in that function.
As you can see that the function is used for generating dynamic SQL queries base on input parameters. And, there is only #PrimaryValue parameter came from user input while other dynamic variables behind SELECT, FROM, JOIN, ON and WHERE are queried from database (not from user input).
How do you think about this case? Can I propose a mitigation for this it or I have to modify the code more to solve the problem? Please advice for me.
Your code has SQL injection problem. For example user can pass to this method, param "intofile" like this:
* FROM Table1; DROP TABLE table2; intofile
With this code user convert your query to 3 queries and after run it table2 is drop.
First of all you have to run your query in a read only transaction. After that you have to use a SQL escape method over all inputs to delete key words like DROP from it.
Related
Also posted on super users:
I'm a spotfire novice trying to create a parameterized info link. Ultimate goal is to create a default template that may be customized to return specific rows in a very large table. I've not been able to cobble together enough information from online searches to get me from point A to Z.
Spotfire version is 7.11 on an Oracle 11.2 SE DB.
Currently I've got a date/time prompt in the info link that will be global to all users. What I need is to be able to further filter to 1 of 2 columns (one is real, the other a string) in order to minimize loading times. There are 17 other on-demand tables that are related to the main one. Limiting the initial query will greatly speed up performance.
In information designer for the information link, if I edit the SQL in the WHERE and explicitly define the value or string for the column, I get the rows I want. When I try to define it using an input parameter (?ParamName), I either get nothing when I reload or get asked to input a parameter "for testing".
Q1: In the document properties for the analysis, I've been adding in properties that I assume is supposed to get picked up by the query.
- What part do scripts play in passing this variable to the SQL?
- Do I just need to define a value for a property name or include a IronPython script? - If script is required, can I just define the parameter to pass?
Q2: In the info link SQL, what is the correct syntax for defining the parameter variable depending on the type (real v string)? If I use a string, I need to include LIKE in order to pick up the desired rows. If I use a real, is it possible to define it as a list of values?
Thanks in advance.
Though not exactly clear from your description, I think you should be able to accomplish your goals using the "Load on demand" dialog that is accessed either when you add your data table to your analysis, or subsequently using the Data Table Properties>Type of Data>Settings dialog.
Spotfire uses this dialog to dynamically modify your SQL. Thus, you do not need to explicitly include the LIKE statement in your SQL. Spotfire will add it in based on what you define in the On-Demand settings. For example, you could have an Input Field where you type a constraint that will be stored as a Document Property and then refer to that Document Property in your On-Demand settings to control the table loading.
I have a query like;
SELECT
*
INTO [documentdb]
FROM
[iothub]
TIMESTAMP BY eventenqueuedutctime
I need to use * because data is dynamic and dont have specific schema. Problem is Iothub system information data is written to documentdb in this query. Is there any way to exclude Iothub system information data?
Thanks.
This is not possible currently but this will be possible in Job Compatibility Level 1.2 in near future. For now, one workaround is that you could create a post create trigger in Cosmos DB to remove this property from the document.
To answer your question, Azure stream analytics service doesn't have an in-built support for excluding columns from dynamic data (iothub information). But, we can achieve this by using UDF. Here is more info on UDF.
UDF can help us in deleting the column from input data and returning us the updated json.
There are two steps basically to achieve this:
Create a JavaScript UDF.
Go to functions from left hand side navigation (below inputs).
Click on Add --> JavaScript UDF.
Give a function alias = removeiothubinfo
keep output type - any.
copy paste following code into function definition.
function main(input) {
delete input['IoTHub'];
return input;
}
Click on Save
Update query
Go to query mode and copy paste the following query :
WITH NewInput AS
(
SELECT
udf.removeiothubinfo(iothub) AS UpdatedJson
FROM
[iothub]
)
SELECT
UpdatedJson.*
INTO
[documentdb]
FROM
NewInput
Click on Save
I suggest you to test your query before running the job by uploading a sample file containing similar structure for json.
Edited
Also, even in job compatibility level 1.2 there has been no additional functionality to achieve this. Check this out for more info.
As #chetangm said in his answer, no such filtering mechanism is supported in ASA so far. Yes, you could use create trigger in Cosmos db, however it need to be triggered in sdk code or REST API. It won't be triggered automatically.
I provide you with another workaround that using Azure Function Cosmos DB Triggered. It could be executed when data is added to or changed in Azure Cosmos DB. You just need to remove the fields you don't want in the function code.
I would like to create an express middleware function that examines a sql string (could be either select/insert/update/delete) and extracts the names of the participating tables in the query.
for specific tables I would then have the middleware function add conditions based on application's permission definitions.
I see for select statements I could use views and extract the information from information_schema.view_table_usage. can I extract this info for arbitrary sql ?
basically you can only check return data. BUT: let us assume the following query ...
SELECT function();
function() is a blackbox ... it can touch anything anywhere. so, you can inspect the return data and maybe identify a table but you can certainly not see, what has been used inside the query to actually get to the result.
HI,
I have a SP which returning more than 100 fields with 1000+ row. I need to to save all in temp table and and rum my customize query to get the appropriate data.
I did many search but i am unable to find the right solutions for my project. I will appreciate if anyone can share his idea.
create table #SP_Result
(i need to create field dynamically according to the SP return result )
exec Ministry..civil_record
"2010-08-07","Autogen",20,NULL,NULL,NULL,NULL,NULL,NULL,NULL
I need dump the result from SP to #SP_Result.
Why don't you run the query itself, in your "customised query", rather than try to capture the result set of the stored proc ? That's the normal method.
All those Nulls look like a bastard of a de-normalised "table", where many rows will not apply to the task. It is much, much faster to deal with the database in a normalised, set-oriented manner.
I've got a Subsonic query that isn't returning any values. I think the problem is in my where clause, although I'm not sure why.
What I'm really looking for is a way to debug the query to see the SQL that's actually being spit out by Subsonic. I know there was a way to do this with the Query object with Inspect(), but I'm using Select objects (or could also probably use SQLQuerys) because I need joins. Is there any inspect() type option for a Subsonic Select?
Here's the code I'm using:
Dim qry As New [Select]("Contract_NO")
qry.From(<table1>.Schema)
qry.InnerJoin(<table2>.<table2columnA>, <table1>.<table1columnA)
qry.Where(NonInfoleaseLessor.Columns.LessorCode).Like("mystring")
If I comment out the where line, I get a full list of results. It doesn't like something about it, but I've manually run the query at the database with that where clause, and it works. How can I see what the difference is?
The problem with your query is that you should be using Contains("mystring") instead of Like("mystring").
The best way to see the SQL is to use the BuildSqlStatement() method of the query.
Use [a] profiler to see what SQL is actually being executed against the database.
As Adam spotted:
.Like("mystring")
should most probably be
.Like("%mystring%")
please try using Like("%mystring%")
It might have something to do with your choice of clause, or which column name you are using. Subsonic has a couple of column name field
OBJECT.xyzColumn
OBJECT.xyzColumn.QualifiedName
OBJECT.Columns.xyz
I have had to play with these in the past to get the values I wanted.