Every one can inject code SQL in select or radio or checkbox field value (See attachment).
i use just a select command, the hackers can use any command as he wishes.
this issue exists in all fields has an ajax lookup
1 Like
I haven’t done it myself … but have you tried the macro sc_sql_injection?
Ex. 1: Protecting a local variable:
$field_protect = sc_sql_injection({my_field});
I’m agree with if we talk about events
but in lookup field PHP code doesn’t work, we can put only sql code
Use PDO when setting up your database connection.
Have a look at this article:
I use MSSQL
its a general issue
you can test on your generated applications if you have a lookup field, every one can inject sql code on your field, example on picture above.
this example is from scriptcase samples on their website.
1 Like
I will do that. In the interim … here’s a php article on PDO with MSSQL.
https://www.php.net/manual/en/ref.pdo-dblib.php
My guess is that SC, when building samples, are showing the features of the software … and the sample is just a quick and dirty little thing to show us that feature … I know that in most of their samples that I’ve looked at they are using a SQLITE database - which is nothing but a text file really. I have yet to take a sample from SC and use it right out of the box; lots of coding to make it do what I want.
Thank you for your time,
Me too i make a lots of coding to make what i want, but in ajax lookup function (Not a macro picture below) you can’t code anything because you do it via scriptcase interface and you can’t put any php code.
how can i protect my {region_candidat} variable in this case.
I will play with it and see if I can reproduce the issue. I haven’t encountered anything like that. I am using a PDO driver on mySQL - but I also have MSSQL here so maybe I’ll make a connection to that.
bhardin,
you can test also with mysql, it’s a serious problem
for mysql and linux i fix the problem with centos firewall (it bloc any sql javascript code exists in http request) but windows and MSSQL i have this issue
Regards
1 Like
Hi achekra,
did you get any response from SC about this?
It a very big problem
1 Like
Hi aamartinezz,
not yet.
1 Like
It could be a workaround, what do you think?
In MYSQL something like that
CREATE FUNCTION SQL_INJECTION(CAMPO TEXT) RETURNS text CHARSET utf8 COLLATE utf8_bin
BEGIN
DECLARE RESULTADO TEXT DEFAULT “”;
SET RESULTADO=REPLACE(CAMPO, ‘’’’,’’);
SET RESULTADO=REPLACE(RESULTADO, ‘&’,’’);
SET RESULTADO=REPLACE(RESULTADO, ‘/’,’’);
SET RESULTADO=REPLACE(RESULTADO, ‘"’,’’);
SET RESULTADO=REPLACE(RESULTADO, ‘?’,’’);
RETURN RESULTADO;
END
then in your SC code (WHERE)
SQL_INJECTION({campo})
1 Like
Yep it’s a good idea, but you need a second parameter to protect your query
if some one add in your input value something like
<option value="0); truncat your_table --" ></option>
he can access to your database
add a second parameter as a secret key (token) and verify this token inside your function.
for that i created an MSSQL function to protect my inputs as
SQL_INJECTION({campo},token);
Also I created and used a second MSSQL user with only a select privilege for all lookup field.
Sincerely scriptcase is a good RAD but needs more improvements.
I agree about SC.
But the token is not changed if someone change the field, How do you know it’s a valid request?
my query seems like bellow
select ID_CAMPO,DESC_CAMPO from TABLE where ID_PARENT = SQL_INJECTION({campo},‘here_your_token’)
Inside your function you verify if the token is equal ‘here_your_token’ before to return your value.
you can put your token inside a field as dynamic or just put your token on your code.
sorry i forgot to precise the hacker must to close the function if he want execute other query.
1 Like
Can you elaborate a bit more on how you did this with the Firewall?
Thanks!
I am no sure what you mean by ajax lookup?
in my case i see dropdown list items are rendered as a html items list, how can you inject something here?
Your select element is hidden, you can find it ahead your list html