nahsra
How to solve the problem of " being escaped in json strings
Input: { "names":"["alex","bob"]" } Expected output: { "names":"["alex","bob"]" } Current output: { "names":"[&quto;alex&quto;,&quto;bob&quto;]" }
antisamy version: 1.7.7
Can you please explain how you are using AntiSamy to do this? We need more details to be able to review/respond appropriately. cc @spassarop
Can you please explain how you are using AntiSamy to do this? We need more details to be able to review/respond appropriately. cc @spassarop
When using AntiSamy as an XSS filter, if your input parameters contain JSON strings and you want to avoid converting escaped characters like " back to " after processing, here's the solution:
Problem Analysis AntiSamy automatically escapes special characters to sanitize HTML/XML contexts. However, this breaks JSON validity if the input is a JSON string (e.g., {"key":"value"} becomes {"key":"value"}).
@aduoer - Can you edit your response to properly escape it, because all your encoded stuff is decoded automatically when viewing it. You need to look at the 'Preview' view to make sure it looks like you intend.
Also, it would be better to provide a Java test case so it can be debugged with the expected behavior.
Can you please explain how you are using AntiSamy to do this? We need more details to be able to review/respond appropriately. cc @spassarop
When using AntiSamy as an XSS filter, if your input parameters contain JSON strings and you want to avoid converting escaped characters like " back to " after processing, here's the solution:
Problem Analysis AntiSamy automatically escapes special characters to sanitize HTML/XML contexts. However, this breaks JSON validity if the input is a JSON string (e.g., {"key":"value"} becomes {"key":"value"}).
It sounds as though perhaps you are using an interceptor type of approach such as a Spring Interceptor or Java EE (or Jakarta) Servlet Filter. If you are in fact using AntiSamy as a general solution to address all your XSS defenses using an approach like that and you believe that alone is sufficient, you are unfortunately wrong. That is a popular anti-pattern that was spread through misinformed web articles in the early 2000s and then took on a life of their own when the were the top answer in Stack Overflow when searching for "XSS defense". Recently, I added the section "Common Anti-patterns: Ineffective Approaches to Avoid" in the "OWASP Cross Site Scripting Prevention Cheat Sheet". If that indeed is what you are doing, you definitely should read at least that section.
