API Connect

Could you please share github link if the  sample sql injection policy is implemented for XML and json messages ? it would be great if you suggest how to implement by using existing templates

Hi Santhoshkumar,
Please see the DataPower documentation https://www.ibm.com/docs/en/datapower-gateway/10.5.0?topic=wizards-protection-against-code-injection-attacks.   In API Connect, the xslt policy does not have a stylesheet parameter as would  a xform or filter action used by the MPGW, but the code in store:///SQL-Injection-Filter.xsl can still be used as a template.   Since that stylesheet parameter provides a url to a pattern file similar to the store:///SQL-Injection-Patterns.xml sample which is intended for users to use as a starting point to create their own pattern file, you'll need to do the same and then deploy that file to your gateways, best done by an manifest.json type of extension in a gateway-extension.zip.  The stylesheet code then will need to be updated to remove the dpconfig namespaced functions that get this file name (and perhaps other parameters) from a stylesheet parameter to instead using either a) hardcoded if using a xslt policy b) if you place this modified stylesheet into a user defined policy, then the UDP could have this url and other properties as a UDP policy property which could be used instead and then referenced by the stylesheet using code, for example, the current code there is:

 <xsl:variable name="patterns" select="document( $dpconfig:SQLPatternFile )"/>

but change that to

 <xsl:variable name="patterns" select="document(apigw:get-variable('local.parameter.SQLPatternFile'))"/>

assuming of course that your UDP property is named SQLPatternFile and don't forget to also define the apigw namespace in your xsl:stylesheet element, probably best when removing all of the dpconfig functions in the xsl in the process

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"                              xmlns:dp="http://www.datapower.com/extensions"                              xmlns:regexp="http://exslt.org/regular-expressions"                              xmlns:apigw="http://www.ibm.com/xmlns/datapower/2017/11/apigateway"                              extension-element-prefixes="dp regexp apigw"                              exclude-result-prefixes="dp regexp apigw">

I believe this stylesheet believes the MPGW processing action's input context is where it gets the payload.  Although you could configure an XSLT policy to consume as it's input the contents of message.body by checking the use input option, you could use both XML and JSON payloads by not selecting this xslt policy option and instead reading the current payload by using

 <xsl:variable name="input" select="apigw:get-variable('message.body')"/>

If message.body is XML, then the input variable will be that XML, but if it is JSON, then the input variable will be returned as JSONx, an XML representation of the JSON, which I believe the stylesheet and pattern file would still operate against.  The stylesheet has

        <xsl:variable name="content" select="normalize-space( string( . ) )"/>	    <xsl:if test="$dpconfig:SQLDEBUG">              <xsl:message dp:priority="debug" dp:id="{$DPLOG_SQL_INJECTION_ALL_ELEMENT_VALUE}">                <dp:with-param value="{$content}"/>               </xsl:message>	    </xsl:if>

so that would need to be changed to use string($input) instead of string(.) and finally note where there is usage of $dpconfig such as $dpconfig:SQLDEBUG in the above statement, then SQLDEBUG is also a stylesheet query parameter which would also be a candidate for a UDP property as would any other  dpconfig variable.

Bottom line I think you can use the sample stylesheet provided for you but you'd need to modify it to work in an API Connect environment.   I'd recommend an xslt policy in a UDP where the UDP parameters match the stylesheet parameters assumed by the current xslt, and finally a change in getting the content to validate by using the apigw function instead of assuming the input payload is passed into the xslt.

And of course, test and verify :-) 

Best Regards,
Steve

Could you please share github link if the  sample sql injection policy is implemented for XML and json messages ? it would be great if you suggest how to implement by using existing templates

Hi Santhoshkumar,
Please see the DataPower documentation https://www.ibm.com/docs/en/datapower-gateway/10.5.0?topic=wizards-protection-against-code-injection-attacks.   In API Connect, the xslt policy does not have a stylesheet parameter as would  a xform or filter action used by the MPGW, but the code in store:///SQL-Injection-Filter.xsl can still be used as a template.   Since that stylesheet parameter provides a url to a pattern file similar to the store:///SQL-Injection-Patterns.xml sample which is intended for users to use as a starting point to create their own pattern file, you'll need to do the same and then deploy that file to your gateways, best done by an manifest.json type of extension in a gateway-extension.zip.  The stylesheet code then will need to be updated to remove the dpconfig namespaced functions that get this file name (and perhaps other parameters) from a stylesheet parameter to instead using either a) hardcoded if using a xslt policy b) if you place this modified stylesheet into a user defined policy, then the UDP could have this url and other properties as a UDP policy property which could be used instead and then referenced by the stylesheet using code, for example, the current code there is:

 <xsl:variable name="patterns" select="document( $dpconfig:SQLPatternFile )"/>

but change that to

 <xsl:variable name="patterns" select="document(apigw:get-variable('local.parameter.SQLPatternFile'))"/>

assuming of course that your UDP property is named SQLPatternFile and don't forget to also define the apigw namespace in your xsl:stylesheet element, probably best when removing all of the dpconfig functions in the xsl in the process

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"                              xmlns:dp="http://www.datapower.com/extensions"                              xmlns:regexp="http://exslt.org/regular-expressions"                              xmlns:apigw="http://www.ibm.com/xmlns/datapower/2017/11/apigateway"                              extension-element-prefixes="dp regexp apigw"                              exclude-result-prefixes="dp regexp apigw">

I believe this stylesheet believes the MPGW processing action's input context is where it gets the payload.  Although you could configure an XSLT policy to consume as it's input the contents of message.body by checking the use input option, you could use both XML and JSON payloads by not selecting this xslt policy option and instead reading the current payload by using

 <xsl:variable name="input" select="apigw:get-variable('message.body')"/>

If message.body is XML, then the input variable will be that XML, but if it is JSON, then the input variable will be returned as JSONx, an XML representation of the JSON, which I believe the stylesheet and pattern file would still operate against.  The stylesheet has

        <xsl:variable name="content" select="normalize-space( string( . ) )"/>	    <xsl:if test="$dpconfig:SQLDEBUG">              <xsl:message dp:priority="debug" dp:id="{$DPLOG_SQL_INJECTION_ALL_ELEMENT_VALUE}">                <dp:with-param value="{$content}"/>               </xsl:message>	    </xsl:if>

so that would need to be changed to use string($input) instead of string(.) and finally note where there is usage of $dpconfig such as $dpconfig:SQLDEBUG in the above statement, then SQLDEBUG is also a stylesheet query parameter which would also be a candidate for a UDP property as would any other  dpconfig variable.

Bottom line I think you can use the sample stylesheet provided for you but you'd need to modify it to work in an API Connect environment.   I'd recommend an xslt policy in a UDP where the UDP parameters match the stylesheet parameters assumed by the current xslt, and finally a change in getting the content to validate by using the apigw function instead of assuming the input payload is passed into the xslt.

And of course, test and verify :-) 

Best Regards,
Steve

Could you please share github link if the  sample sql injection policy is implemented for XML and json messages ? it would be great if you suggest how to implement by using existing templates

I made changes and it is working for sql key words  (select , delete) )  but not for symbols  % and Like words and It is not working with attribute values and i attached changes which i made to script .I kept the below script in xslt policy for testing purpose.

sample payload

Hi Santhoshkumar,
Please see the DataPower documentation https://www.ibm.com/docs/en/datapower-gateway/10.5.0?topic=wizards-protection-against-code-injection-attacks.   In API Connect, the xslt policy does not have a stylesheet parameter as would  a xform or filter action used by the MPGW, but the code in store:///SQL-Injection-Filter.xsl can still be used as a template.   Since that stylesheet parameter provides a url to a pattern file similar to the store:///SQL-Injection-Patterns.xml sample which is intended for users to use as a starting point to create their own pattern file, you'll need to do the same and then deploy that file to your gateways, best done by an manifest.json type of extension in a gateway-extension.zip.  The stylesheet code then will need to be updated to remove the dpconfig namespaced functions that get this file name (and perhaps other parameters) from a stylesheet parameter to instead using either a) hardcoded if using a xslt policy b) if you place this modified stylesheet into a user defined policy, then the UDP could have this url and other properties as a UDP policy property which could be used instead and then referenced by the stylesheet using code, for example, the current code there is:

 <xsl:variable name="patterns" select="document( $dpconfig:SQLPatternFile )"/>

but change that to

 <xsl:variable name="patterns" select="document(apigw:get-variable('local.parameter.SQLPatternFile'))"/>

assuming of course that your UDP property is named SQLPatternFile and don't forget to also define the apigw namespace in your xsl:stylesheet element, probably best when removing all of the dpconfig functions in the xsl in the process

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"                              xmlns:dp="http://www.datapower.com/extensions"                              xmlns:regexp="http://exslt.org/regular-expressions"                              xmlns:apigw="http://www.ibm.com/xmlns/datapower/2017/11/apigateway"                              extension-element-prefixes="dp regexp apigw"                              exclude-result-prefixes="dp regexp apigw">

I believe this stylesheet believes the MPGW processing action's input context is where it gets the payload.  Although you could configure an XSLT policy to consume as it's input the contents of message.body by checking the use input option, you could use both XML and JSON payloads by not selecting this xslt policy option and instead reading the current payload by using

 <xsl:variable name="input" select="apigw:get-variable('message.body')"/>

If message.body is XML, then the input variable will be that XML, but if it is JSON, then the input variable will be returned as JSONx, an XML representation of the JSON, which I believe the stylesheet and pattern file would still operate against.  The stylesheet has

        <xsl:variable name="content" select="normalize-space( string( . ) )"/>	    <xsl:if test="$dpconfig:SQLDEBUG">              <xsl:message dp:priority="debug" dp:id="{$DPLOG_SQL_INJECTION_ALL_ELEMENT_VALUE}">                <dp:with-param value="{$content}"/>               </xsl:message>	    </xsl:if>

so that would need to be changed to use string($input) instead of string(.) and finally note where there is usage of $dpconfig such as $dpconfig:SQLDEBUG in the above statement, then SQLDEBUG is also a stylesheet query parameter which would also be a candidate for a UDP property as would any other  dpconfig variable.

Bottom line I think you can use the sample stylesheet provided for you but you'd need to modify it to work in an API Connect environment.   I'd recommend an xslt policy in a UDP where the UDP parameters match the stylesheet parameters assumed by the current xslt, and finally a change in getting the content to validate by using the apigw function instead of assuming the input payload is passed into the xslt.

And of course, test and verify :-) 

Best Regards,
Steve

Could you please share github link if the  sample sql injection policy is implemented for XML and json messages ? it would be great if you suggest how to implement by using existing templates

Hi Santhoshkumar,

I'd definitely not a SME on this stylesheet.  I just know it's been around in DataPower since I first started working as a DataPower consultant years ago as samples of what could be done.  Just looking at your concerns:

1. not for symbols  % and Like words - The pattern file has a regular expression of <regex>'[\s]*[\%]+</regex> but your element value does not start with a single quote, so I wouldn't expect hlerjhelj %like% % to match. It's been so long since I used SQL so I did a quick google search of SQL Like I found an example SELECT * FROM Customers WHERE CustomerName LIKE 'a%'; Looking at that SQL statement that is where the single quote must be coming into play in the pattern file where it is expected to be within single quotes.
2. As for LIKE and looking at the pattern file
       <!-- SQL keyword injection -->  
    <pattern type="element">
        <name>SQL Keyword Injection</name>
        <regex>^(insert|as|select|or|procedure|limit|order by|asc|desc|delete|update|distinct|having|truncate|replace|handler|like)$</regex>
    </pattern>   
   That regex is looking at start of string, one of the keywords, and end of string, so I don't believe having like in the middle of a string would match either. At least if I'm reading the regex properly, it would only match elements with only those values.  It would seem to be as if that regex is definitely too simplistic. Perhaps removing the start of text and end of text special characters would match if any of those keywords are in the value.  Just note though https://www.ibm.com/support/pages/customizing-default-sql-injection-protection-ibm-websphere-datapower-soa-appliance which steps you through this with a value of an element begin a state abbreviation of OR and not the SQL OR keyword.
3. It is not working with attribute values - per the documentation in the pattern file, the pattern without a type attribute is global and should be compared against all elements and all attributes, and the if type attribute should just match against attributes.  The only attribute in your example of type="exec sp" which I would think would match the pattern
         <!-- MS SQL Commands -->  
      <pattern>
          <name>MS SQL Commands</name>
          <regex>\b(exec sp|exec xp)\b</regex>
      </pattern>
   As it should be used for attributes and the exec sp does exist between word boundaries of the attribute value, so I don't have a good explanation if you're saying that is failing to match.  As a test I'd say break this up into two separate patterns
         <!-- MS SQL Commands -->  
      <pattern>
        <name>MS SQL Commands 1</name>
        <regex>\bexec sp\b</regex>
      </pattern>
      <!-- MS SQL Commands -->  
      <pattern>
        <name>MS SQL Commands 2</name>
        <regex>\bexec xp\b</regex>
      </pattern>
   and see if that makes a difference.  It shouldn't but test and verify.  Perhaps another test add a space after the xp in the value to see if you've come across a product issue in the regex with \b at the end of a string.  It may also be worth while doing a very simple xslt of your own that simply does the regex:test('exec sp', '\b(exec sp|exec xp)\b') or other combinations to determine if there is a product issue.  If so, open a support ticket.

Regards,
Steve

I made changes and it is working for sql key words  (select , delete) )  but not for symbols  % and Like words and It is not working with attribute values and i attached changes which i made to script .I kept the below script in xslt policy for testing purpose.

sample payload

Hi Santhoshkumar,
Please see the DataPower documentation https://www.ibm.com/docs/en/datapower-gateway/10.5.0?topic=wizards-protection-against-code-injection-attacks.   In API Connect, the xslt policy does not have a stylesheet parameter as would  a xform or filter action used by the MPGW, but the code in store:///SQL-Injection-Filter.xsl can still be used as a template.   Since that stylesheet parameter provides a url to a pattern file similar to the store:///SQL-Injection-Patterns.xml sample which is intended for users to use as a starting point to create their own pattern file, you'll need to do the same and then deploy that file to your gateways, best done by an manifest.json type of extension in a gateway-extension.zip.  The stylesheet code then will need to be updated to remove the dpconfig namespaced functions that get this file name (and perhaps other parameters) from a stylesheet parameter to instead using either a) hardcoded if using a xslt policy b) if you place this modified stylesheet into a user defined policy, then the UDP could have this url and other properties as a UDP policy property which could be used instead and then referenced by the stylesheet using code, for example, the current code there is:

 <xsl:variable name="patterns" select="document( $dpconfig:SQLPatternFile )"/>

but change that to

 <xsl:variable name="patterns" select="document(apigw:get-variable('local.parameter.SQLPatternFile'))"/>

assuming of course that your UDP property is named SQLPatternFile and don't forget to also define the apigw namespace in your xsl:stylesheet element, probably best when removing all of the dpconfig functions in the xsl in the process

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"                              xmlns:dp="http://www.datapower.com/extensions"                              xmlns:regexp="http://exslt.org/regular-expressions"                              xmlns:apigw="http://www.ibm.com/xmlns/datapower/2017/11/apigateway"                              extension-element-prefixes="dp regexp apigw"                              exclude-result-prefixes="dp regexp apigw">

I believe this stylesheet believes the MPGW processing action's input context is where it gets the payload.  Although you could configure an XSLT policy to consume as it's input the contents of message.body by checking the use input option, you could use both XML and JSON payloads by not selecting this xslt policy option and instead reading the current payload by using

 <xsl:variable name="input" select="apigw:get-variable('message.body')"/>

If message.body is XML, then the input variable will be that XML, but if it is JSON, then the input variable will be returned as JSONx, an XML representation of the JSON, which I believe the stylesheet and pattern file would still operate against.  The stylesheet has

        <xsl:variable name="content" select="normalize-space( string( . ) )"/>	    <xsl:if test="$dpconfig:SQLDEBUG">              <xsl:message dp:priority="debug" dp:id="{$DPLOG_SQL_INJECTION_ALL_ELEMENT_VALUE}">                <dp:with-param value="{$content}"/>               </xsl:message>	    </xsl:if>

so that would need to be changed to use string($input) instead of string(.) and finally note where there is usage of $dpconfig such as $dpconfig:SQLDEBUG in the above statement, then SQLDEBUG is also a stylesheet query parameter which would also be a candidate for a UDP property as would any other  dpconfig variable.

Bottom line I think you can use the sample stylesheet provided for you but you'd need to modify it to work in an API Connect environment.   I'd recommend an xslt policy in a UDP where the UDP parameters match the stylesheet parameters assumed by the current xslt, and finally a change in getting the content to validate by using the apigw function instead of assuming the input payload is passed into the xslt.

And of course, test and verify :-) 

Best Regards,
Steve

Could you please share github link if the  sample sql injection policy is implemented for XML and json messages ? it would be great if you suggest how to implement by using existing templates