Feedback
Did this article resolve your question/issue?

   

Article

Is ABL code injection preventable?

« Go Back

Information

 
TitleIs ABL code injection preventable?
URL Name000029761
Article Number000150164
EnvironmentProduct: OpenEdge
Version: All Supported Versions
OS: All Supported Platforms
Other: Code Injection, Security
Question/Problem Description
Is it possible programming in ABL to avoid the risk of code injection when working with dynamic queries?
 
The below example uses the sports2000 database to demonstrate how it's possible to break a dynamic query string with the use of compiler tokens.

In this example, the use of the windows escape char ~ and the comment symbols /* */ is used to exclude one of the hard coded where clauses.
DEFINE VARIABLE cQry           AS CHARACTER   NO-UNDO.

DEFINE VARIABLE cSalesRep AS CHARACTER   NO-UNDO 
    INITIAL 'HXM~~042/*'.
DEFINE VARIABLE cCountry    AS CHARACTER   NO-UNDO 
    INITIAL '*/ and Customer.Country = ~~042USA'.

DEFINE VARIABLE dBalance    AS DECIMAL         NO-UNDO 
    INITIAL 1000.

UPDATE "SalesRep: " cSalesRep.
UPDATE "Country:    " cCountry.

/*
The system prompts the user for the Sales representative code and the country to visualize records, the selection is programatically restricted to accounts with a balance <= 1000
inserting these malicious values it's possible to brake the dynamic query string and overcome the hardcoded 1000 limitation

SalesRep: HXM~042/*
Country: */ and Customer.Country = ~042USA
*/

DEFINE VARIABLE hQry           AS HANDLE         NO-UNDO.

CREATE QUERY hQry.

ASSIGN cQry = "FOR EACH Customer WHERE Customer.SalesRep = " + 
                          QUOTER(cSalesRep) + 
                          " and Customer.Balance <= " +  
                          QUOTER(dBalance) + 
                          " and Customer.Country = " + 
                          QUOTER(cCountry) + " NO-LOCK".

hQry:SET-BUFFERS(BUFFER customer:HANDLE).
hQry:QUERY-PREPARE(cQry).
hQry:QUERY-OPEN().

hQry:GET-FIRST().
DO WHILE NOT hqry:QUERY-OFF-END:
    DISPLAY Customer.NAME 
                    Customer.Country 
                    Customer.SalesRep 
                    Customer.Balance 
        WITH FRAME n DOWN.

    DOWN 1  WITH FRAME n.
    hQry:GET-NEXT().
END.

IF VALID-HANDLE(hQry) AND 
    hQry:IS-OPEN THEN
    hQry:QUERY-CLOSE().
DELETE OBJECT hQry NO-ERROR.

 
Steps to Reproduce
Clarifying Information
Error Message
Defect Number
Enhancement Number
Cause
Compiler tokens like the escape char ~ or comments /* */ are interpreted meaningfully by the query parser creating the risk of injection.
Resolution
The problem can be addressed in ABL applications applying these strategies:
  • Use when possible prepopulated widgets as input method for dynamic queries.  For instance, SELECTION-LIST, COMBO-BOX
  • Compatibly with the nature of the data we are filtering it's possible to restrict special characters as input
  • Compatibly with the nature of the data we are filtering parse the query string before executing it and rise an error if it contains compiler tokens
Workaround
Notes
A google search for SQL code injection exploits identified another example where fora  username or password, the bad guy put in something like
OR 1 = 1. When added the the query , the resultant query was WHERE username = XYZ OR 1 = 1. This would be true in all examples and might give access to more records than was intended. Input from a form used in a dynamic query should be scanned for an exploit as described above.

References to other Documentation:

https://www.acunetix.com/websitesecurity/sql-injection/
https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005)
https://www.w3schools.com/sql/sql_injection.asp
Last Modified Date8/24/2021 1:53 PM
Attachment 
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.