Layer7 API Management

I am trying to secure the API from xss scripting attack. To protect, i have used protect against code injection assertion enabled with HTML/JavaScript Injection (Cross-site Scripting). But it fails in situtation when the request is multiple encoded. Say for example, request with double encoded value like - %253Cscript%253E will become a serious threat if passed. Is there any way to prevent this? Please share your suggestions. 

Thanks, 

Giridharan selvaraj. 

Dear Giridharan_S ,

As per my understanding, the threat protection assertions  are using regex patterns to scan the request messages, the OOTB patterns would not include encodings as it would be relevant with your particular use case.

If you are sure certain patterns have threats, you can use regex assertion in your policy to filter them.

We also provide a tactical assertion -- Injection Filter Assertion, which can let you set the custom patterns.

You can open a support ticket to ask for the tactical assertion.

Regards,

Mark

Hi, 

1. If you have the need to prevent double URL encoded characters, then the best way to do that is to do that in three steps: 

1) Check the variable (var1) for javascript cross site special characters (Protect against Code Injection Assertion)

2) URL Decode the variable to var2. (Encode/Decode Data)

3) Check the variable (var2) for javascript cross site special characters (Protect against Code Injection Assertion)

That may be applicable to what you are trying to do - and in some circumstances that is appropriate to do.

2. But... 

But usually a XSS failure on double URL decoding means someone is not handling the data correctly. 

It means somewhere in the processing, someone does a urldecode, and then passes the data straight into another routine (or backend server) that then also does a urldecode and that backend routine then uses data in its raw form in an unsafe manner.

It's not easy if you are trying to write a front end that "protects" any data sent to the backend server that uses that data, and in your case if the backend does a double urldecode and then uses the data un-safely then all you can do is the steps in 1.

Why you would want to use special characters ? 

Often user entry data is simple and does not need special characters.  But they are occasions you when you want to pass "special characters" through in the data fields.

Some examples :

• My name is Mark O'Donohue, if the single quote is not allowed in the surname field I can't enter that - it has happened more than once; 
• Also entry of a password field may require X numbers, X letters, X uppercase characters, and X special characters.
• If you are posting a document, (such as this community post) then it's handy to be able to use the characters " < > ' and &. when writing it. 

So use of these characters is normal, just care should be made to make sure their usage is safe.

Safe handling of Special Characters : 

The problem happens when data is decoded and directly placed into documents. 

Correct handling of special characters can only be done at the time of use, any time you place rawdata (especially data fields from a front end user) in a SQL stmt or JSON document or the raw html page you need to do the appropriate encoding to escape special characters for that document type.   That may be a : urlencode (or html encode, or sql escape). 

In your case that seems it would be the backend server not doing an escape of the data before use, or you may be able to urlencode the data again before you send it onto the backend server. 

This enhancement would help to assist with API Gateway policy assertions being able to properly re-encode data for xml, html and javascript documents : 

Enhance Encode/Decode Data Assertion to add html encode/decode 

Cheers - Mark

PS: I've had my amex card rejected in three locations, because of the ' in my name, failed to be able to pay for visa to India, not been able to one major telco (that I worked for) because my name didn't match - so use of special characters is a bit personal  :-)