ibnemahdi / owasp-esapi-java

Automatically exported from code.google.com/p/owasp-esapi-java
Other
0 stars 0 forks source link

DefalutValidator.isValidSafeHTML() doesn't work #194

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Scan vunerable HTML it will return true
2. Used the default antisamy-esapi.xml

What is the expected output? What do you see instead?
false

What version of the product are you using? On what operating system?
2.0_rc10 Linux 

Does this issue affect only a specified browser or set of browsers?

Please provide any additional information below.

Reason why it doesn't work is isValidSafeHTML uses getValidSafeHTML and assumes 
an exception will be thrown in case where HTML is invalid.  No execption will 
be thrown. DefaultValidator.getValidSafeHTML() uses HTMLValidation.getValid() 
to clean HTML.  The HTMLValidation.getValid() does clean the HTML.  To correct 
the issue the developers may want to right an HTMLValidation.isValid() 
method... have it call AntiSamy checking if errors are present on the 
CleanResult. If errors exist return false as the HTML isn't clean according to 
the antisamy-esapi.xml policy.

Also consider updating the DefaultSecurityConfiguration.getResourceStream() to 
load configuration files from the classpath.  It seems inconsistent for the 
ESAPI.properties and validation.properties file to be loadable from classpath 
when antisamy-esapi.xml isn't.  I find it natural to add these files to my 
src/main/resource on the maven project which depends on esapi artifact.

I'm going to update the code and create my own version which corrects this 
defect.  Contact me if you'd like a copy of the changed code.

Original issue reported on code.google.com by phillipr...@gmail.com on 28 Dec 2010 at 5:49

GoogleCodeExporter commented 9 years ago
My updates which fix the defect... source modified came from trunk.  
DefaultSecurityConfiguration.java is optional... it allows the 
antisamy-esapi.xml to be loaded from the classpath.

Original comment by phillipr...@gmail.com on 28 Dec 2010 at 6:40

Attachments:

GoogleCodeExporter commented 9 years ago
Updated the attached HTMLValidationRule.java to handle the allowNull case:

/**
     * {@inheritDoc}
     */
    @Override
    public boolean isValid( String context, String input ) {
        try {
            CleanResults results = invokeAntiSamy( context, input );
            if (results == null) {
                if (allowNull) {
                    return true;
                } else {
                    return false;  // Shouldn't happen as ValidationException will be thrown but just in case invokeAntiSamy changes
                }
            }
            return results.getErrorMessages().isEmpty();
        } catch (ValidationException ve) {
            return false;
        }
    }

Original comment by phillipr...@gmail.com on 28 Dec 2010 at 9:57

GoogleCodeExporter commented 9 years ago
Hi, 

Is it changed/Fixed in Esapi2.0.1 final release? We are planning to use 
antiSamy with ESAPI in our project and i need information if we will get error 
results too.

Original comment by shilpi.a...@gmail.com on 9 Aug 2012 at 8:46

GoogleCodeExporter commented 9 years ago
I don't know if its changed in 2.0.1.  I built my own ESAPI with it
fix at my last job.  Recently I just used antiSamy alone to do HTML
validation or purification.  I think its a little simpler.  As ESAPI
is just a pass through for that feature.  I post the code patch need
to fix it in my buy report.  Good Luck.

Original comment by phillipr...@gmail.com on 10 Aug 2012 at 3:25

GoogleCodeExporter commented 9 years ago
Thanks for your input Phillip.

Original comment by shilpi.a...@gmail.com on 10 Aug 2012 at 3:44

GoogleCodeExporter commented 9 years ago
+1 on getting the classpath loading fixed. These inconsistencies make it harder 
for folks to get the library working for eval.

Original comment by pafri...@gmail.com on 17 Aug 2012 at 8:38

GoogleCodeExporter commented 9 years ago
+1 These are exactly the two issues I encountered when trying to use ESAPI 
2.1.0, I hope this will get some priority, especially the method 
"isValidSafeHTML" is really confusing - it's actually saying that 
"<script>alert(1)</script>" is *valid* and *safe* HTML.

Original comment by bre...@gmail.com on 27 Nov 2013 at 5:59

GoogleCodeExporter commented 9 years ago
+1 Tried to use isValidSafeHTML with ESAPI 2.1.0 and stuck with following 
exception. Any resolution?

Caused by: org.owasp.esapi.errors.ConfigurationException: Couldn't find 
antisamy-esapi.xml
    at org.owasp.esapi.reference.validation.HTMLValidationRule.<clinit>(HTMLValidationRule.java:55)
    ... 31 more

Original comment by rushabhd...@gmail.com on 8 Jan 2014 at 7:51

GoogleCodeExporter commented 9 years ago
This is scheduled for v2.2

Original comment by chrisisbeef on 18 Sep 2014 at 8:41

GoogleCodeExporter commented 9 years ago

Original comment by chrisisbeef on 18 Sep 2014 at 8:41

GoogleCodeExporter commented 9 years ago

Original comment by kevin.w.wall@gmail.com on 23 Sep 2014 at 1:51

GoogleCodeExporter commented 9 years ago

Original comment by kevin.w.wall@gmail.com on 27 Sep 2014 at 3:09