Comments (8)
I thk you need this:owasp-java-encoder
from antisamy.
@goshantmeher I would speculate that the reason that AntiSamy does things this way is that there are browsers out there that will attempt to fill the missing ">" (or "/>", as the case may be). (That is, the follow Postel's Law, sometimes to the detriment of security.)
If you know that the input is like this and that what you expect the output to look like, then hopefully you also know the context of where the output will be placed, and thus @xtay004 is correct in stating that output encoding using something like the OWASP Java Encoder project is the way to go. In general, output encoding is preferred over HTML "sanitization" as a defense against XSS anyway since it is "less destructive" in that it will leave more of the original input rendered than an HTML sanitizer like AntiSamy or the Java HTML Sanitizer project will. HTML sanitization is intended when you have to accept HTML markup, but otherwise output encoding generally should be preferred.
from antisamy.
Thanks, it works.
For Ref: https://www.owasp.org/index.php/OWASP_Java_Encoder_Project#tab=Use_the_Java_Encoder_Project
from antisamy.
@kwwall, the thing we are doing is on the form submit, we are using org.owasp.validator.html.CleanResults.getCleanHTML() within RequestValidator.validate() to validate all the input fields before saving all data in DB.
if I use Encoder during this, all field values which have let say '<hello', it will return encoded '<hello' string and this value will get saved in DB. which is wrong for me.
For defense against XSS, want to remove only all HTML tags, non-html tags should not be get removed.
The need of mine is I have a Textarea field where I will input any string as description, where it may have <aaaa , and it should get saved.
Please give me a solution for this.
from antisamy.
XSS encoding should only be done right before that content is included in the server response and not before. I.e., it should NOT be done before storing the data in the database or anywhere else for that matter, as you don't know for certain everywhere that data is going. Sanitization really should only be done right before rendering to the browser too. My suggestion is to validate the input and reject what you don't like, and then assume that potential XSS attacks still can sneak through, so whenever you include that data in a full page response (and is thus subject to XSS), then you output encode using the OWASP Java Encoder library. If you are instead including the 'dangerous' data in JSON responses, its actually not vulnerable to XSS, because your JavaScript is very likely to add that data to the DOM in a way that is immune to XSS.
from antisamy.
Ok, I understand the issues but for the case what users will input is not in my control. for now, it means I can't use in-between '<>', which is not acceptable.
for now, I want when there will be input and output should be
So my request in this issue is, can anyone provide me a feature to allow all unknown tags.
from antisamy.
Ok, I understand the issues but for the case what users will input is not in my control. for now, it means I can't use in-between '<>', which is not acceptable.
for now, I want when there will be input and output should be
So my request in this issue is, can anyone provide me a feature to allow all unknown tags.
@goshantmeher You say you are understanding @davewichers' comment, but I'm not sure you do. Cleansing via AntiSamy (or the OWASP Java HTML Sanitizer) is very different than output encoding, and almost all of us in the AppSec community consider it to be an XSS defense of last resort. The bottom line is, it doesn't matter if you store the raw, dangerous user input if you always ensure that you properly output encode it (properly, as in "using the output encoding for the appropriate context") before it is rendered in a browser. Yes, that requires a lot more work on your part, but it is much more bullet-proof then what you are proposing. That said, if you really want to insist on shooting your foot (if not your entire leg) off, you can customize AntiSamy's 'antisamy.xml' file to make it accept whatever you want. But CAVEAT EMPTOR; you have been warned.
from antisamy.
As I don't think it is appropriate/practical for AntiSamy to implement this change, I'm closing this issue.
from antisamy.
Related Issues (20)
- Removing Xerces dependency? HOT 3
- Does Antisamy has support for custom css properties " --* " and css-function " var() " and how to define it in the antisamy policy file? HOT 10
- Enabled noopenerAndNoreferrerAnchors policy drops nofollow HOT 7
- Covering all cases of "rel" attribute in "anchor" tag is quite verbose HOT 3
- Investigate replacing Batik CSS HOT 1
- Dealing with Security Vulnerabilities CVE-2023-26119 HOT 13
- AntiSamy encodes unknown tags despite not being configured that way HOT 6
- GraalVM Support HOT 4
- noopenerAndNoreferrerAnchors policy directive seems disabled by default in 1.7.2 version HOT 2
- How to find if vulnerable script is present in the input HOT 8
- Is there a way to not encode certain HTML Entities? HOT 6
- antisamy:1.7.3 contains batik-css:1.16 that has CVE-2022-44729 vulnerability HOT 1
- Sanitized output for same tainted input differs from AntiSamy 1.7.3 to 1.7.4 HOT 6
- Regex named: "Paragraph", is causing "StackOverFlowError" HOT 8
- the argument 'policy' never be used HOT 1
- antiSamy.scan(input, policy) giving the following as not a valid html. HOT 8
- Prevent formatting and translation of css HOT 3
- Antisamy 1.7.5 version - <body> tag issue HOT 34
- When my runtime environment is a Chinese encoding environment, the list of error messages returned is garbled HOT 3
- Selfclosing Break Line Tag <br /> tag in html content is converted into <br> open tag. HOT 19
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from antisamy.