PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV 23 → WebDev and SQL Injection
WebDev and SQL Injection
Débuté par Glenn Rathke, 30 mai 2007 08:45 - 12 réponses
Posté le 30 mai 2007 - 08:45
Is SQL Injection something we have tgo be conerned with, or does WebDev shield us from that ?
Thanks
Glenn
Posté le 01 juin 2007 - 18:28
Is SQL Injection something we have tgo be conerned with, or does WebDev shield us from that ?
Thanks
Glenn

Sorry Glenn, but what is SQL Injection?
Regards,
Huib.
Posté le 25 juillet 2007 - 19:26
Glenn Rathke escribió:
Is SQL Injection something we have tgo be conerned with, or does WebDev shield us from that ?
Thanks
Glenn







No SQL injection needed. You write simple windev/webdev code.
Posté le 06 janvier 2011 - 00:27
Are all WinDev/WebDev developpers that retarded?

Francisco Acedo wrote in news message <46a7691a@news.pcsoft.fr>:


Glenn Rathke escribió:
Is SQL Injection something we have tgo be conerned with, or does WebDev shield us from that ?
Thanks
Glenn







No SQL injection needed. You write simple windev/webdev code.
Posté le 06 janvier 2011 - 17:09
SQL Injection is a wide spread security risk. See here:

http://en.wikipedia.org/wiki/SQL_injection

I am not aware of any special security mechanism in WinDev. I use a lot of StringBuild() in my code, something like this:

sSQLString = StringBuild( sSQLString,Replace(CurrentWord,";","") )


HTH
Sebastian
Posté le 06 janvier 2011 - 18:36
Hi Sebastian

in fact, as long as your ar enot using the hexecuteWithoutCorrection
parameter, the SQL is interpreted and checked by HF before being run, so
in most case, there is no possible SQL injection

Best regards


--
Fabrice Harari
International WinDev, WebDev and WinDev mobile Consulting

More information on http://www.fabriceharari.com


On 06/01/2011 11:09, Sebastian Arnold wrote:
SQL Injection is a wide spread security risk. See here:

http://en.wikipedia.org/wiki/SQL_injection

I am not aware of any special security mechanism in WinDev. I use a lot of StringBuild() in my code, something like this:

sSQLString = StringBuild( sSQLString,Replace(CurrentWord,";","") )


HTH
Sebastian
Posté le 10 janvier 2011 - 14:52
Hello Fabrice,

I disagree :)

SQL injection can not be discovered from WinDev because its usual SQL code.

See this video: http://ur6.de/sqlinjection

This is the code for the Go button:

sSQLStatement is string
IF EDT_Name <> "" THEN
sSQLStatement = "INSERT INTO MyTable VALUES ('" + EDT_Name + "')"
EDT_Result = sSQLStatement
END


I think that most of the entry fields will look like this. See my above statement to prevent SQL injection.

Sebastian
Posté le 10 janvier 2011 - 16:48
Hi Sebastian

in that case, you should take it to PCSoft, as my answer is coming
straight from information available on their web site, in the
documentation of HyperfileSQL



Best regards

--
Fabrice Harari
International WinDev, WebDev and WinDev mobile Consulting

More information on http://www.fabriceharari.com


On 10/01/2011 08:52, Sebastian Arnold wrote:
Hello Fabrice,

I disagree :)

SQL injection can not be discovered from WinDev because its usual SQL code.

See this video: http://ur6.de/sqlinjection

This is the code for the Go button:

sSQLStatement is string
IF EDT_Name<> "" THEN
sSQLStatement = "INSERT INTO MyTable VALUES ('" + EDT_Name + "')"
EDT_Result = sSQLStatement
END


I think that most of the entry fields will look like this. See my above statement to prevent SQL injection.

Sebastian
Posté le 17 mars 2015 - 14:11
Hi Fabrice,

I can see this thread is very old, but was the discussion regarding the risks of SQL Injection in HFSQL ever resolved?

As developers what do we have to do programmatically to reduce or eliminate this risk in our WebDev applications and what is unique in HFSQL that assists with reducing or eliminating this risk?

The PC Soft Documentation for HFSQL 19 on page 11, makes a very bold statement in a heading "SQL INJECTION NOT POSSIBLE". Is this true?

The reason for my query is we have a client, a bank, who is in the process of completing their PCI DSS compliance and the consultant is asking us the questions above, relating to a web application we have developed.

Kind Regards
Gary Lord
FinDev Services P/L
Membre enregistré
31 messages
Posté le 17 mars 2015 - 14:46
Can't say I'm an expert on the matter, nor do I have too many years of experience, but what I recommend is to limit the use of hExecuteSqlQuery() as much as possible and instead opt to use built-in, parameter-ized queries for any queries whose parameters are public-facing (like getting a parameter from an editable control accessible by the end-user). That's not going to ensure that your product is 100% secure from SQL-injection BUT it's a start, and a good one at that.
Posté le 17 mars 2015 - 16:39
Hi Gary

You will have to ask pcsoft directly if you want more detailed
information...

However, the main difference here is that if you use a hexecutequery
(and NOT the hexecuteWithoutCorrection parameter), then the query is NOT
executed as is... Instead, it is rebuild in the target DB syntax by
their engine... It will therefore be a different SQL code that the one
that went in, whether you use the query editor OR NOT...

Furthermore, as long as you do not give direct access to the DB (in the
HFSQL control center, by example, which should be protected by a good
password), all queries have to go through your application... And
nothing obliges you to let users enter SQL syntax, when you can in its
place offer a series of parameter values to enter in fields...

So I find the possibility of SQL injection in HFSQL VERY REMOTE on a
theoretical standpoint...

If you add to that :
- that your DB should be encrypted and password protected,
- That you should NOT provide ODBC or OLEDB access to it
- That any external access can be done via a webservice or API that YOU
control and secure
....
ONLY your application will be able to access it... There is no entry
point for SQL injection...

Best regards

--
Fabrice Harari
International WinDev, WebDev and WinDev mobile Consulting

NEW: WXReplication, your open source replication system is available on
my web site!!!
WXShowroom.com: Show your projects!
More information on http://www.fabriceharari.com


On 3/17/2015 8:11 AM, Gary Lord wrote:
Hi Fabrice,

I can see this thread is very old, but was the discussion regarding the
risks of SQL Injection in HFSQL ever resolved?

As developers what do we have to do programmatically to reduce or
eliminate this risk in our WebDev applications and what is unique in
HFSQL that assists with reducing or eliminating this risk?

The PC Soft Documentation for HFSQL 19 on page 11, makes a very bold
statement in a heading "SQL INJECTION NOT POSSIBLE". Is this true?

The reason for my query is we have a client, a bank, who is in the
process of completing their PCI DSS compliance and the consultant is
asking us the questions above, relating to a web application we have
developed.

Kind Regards
Gary Lord
FinDev Services P/L
Membre enregistré
4 messages
Posté le 10 août 2018 - 16:59
Hey everyone,

This thread is really old, but I feel obliged to add in because the misinformation concerning SQL injection is flagrant, and you should ABSOLUTELY NOT be coding a publicly available web site if you do not know what SQL injection is and how to manage it properly.

First of all, ALL DATABASES ENGINES (yes, all of them) are vulnerable to SQL injection. A database engine cannot make the distinction between injected SQL code and normal SQL code, this is why it's such an important security aspect to design your program around. It is 100% your responsibility (both legally and ethically) to make sure there is no possible way a user can inject SQL code in one of your queries. You WILL be taken to court if an SQL injection is performed and your customer's data is leaked.

Fabrice, you are wrong.

Furthermore, as long as you do not give direct access to the DB (in the
HFSQL control center, by example, which should be protected by a good
password), all queries have to go through your application... And
nothing obliges you to let users enter SQL syntax, when you can in its
place offer a series of parameter values to enter in fields...

So I find the possibility of SQL injection in HFSQL VERY REMOTE on a
theoretical standpoint...


HFSQL is no more secure than any other database engines against SQL injection, and you absolutely DO NOT require direct access to the DB to perform an SQL injection. Any field where a user can type a value and where that value is used at some point in a query, it is vulnerable to SQL injection. Whether it's for a login field, a message field, a search field, a comment field, they must ALL be checked for SQL injection.

Now, there's two ways to prevent an SQL injection.

The first one (the classical way) is to pass the user input to a dedicated function (that you must code) that will detect if SQL code was written in the input. If the user input does not contain SQL code, it is safe to execute the query with that string.

The second one gives all the control to WinDev/WebDev and assumes that it can accurately detect SQL injection. From the PCSoft docs found here: https://doc.pcsoft.fr/en-US/?3044084

Bad way to do it:
// Build the query by concatenation
sdQuery is Data Source
HExecuteSQLQuery(sdQuery, "SELECT * FROM customer WHERE name = '" + EDT_Name + "'")


Good way to do the same thing:
// Using parameters in the query
sdQuery is Data Source
sdQuery.p_name = EDT_Name
HExecuteSQLQuery(sdQuery, "SELECT * FROM customer WHERE name={p_name}")


Hopefully now everyone (including future readers) better understands how to prevent SQL injection. If you still don't, PLEASE go watch YouTube videos explaining the concepts and how an SQL injection is made. I cannot emphasize enough how important it is to prevent these types of attacks.
Membre enregistré
4 messages
Posté le 11 août 2018 - 21:06
Here's an excellent informative video which demonstrates how EASY it is to perform an SQL injection on an unsecured web page It's 17 minutes long (in english) but I recommend that anyone who dosen't know very much about SQL injection to go watch this.



And no, changing your information schema / table names from the default is not a proper way to protect against this. Security through complexity is never secure 8)