esapi-java-legacy
esapi-java-legacy copied to clipboard
ESAPI
DefalutValidator.isValidSafeHTML() doesn't work
From [email protected] on December 28, 2010 12:49:20
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: http://code.google.com/p/owasp-esapi-java/issues/detail?id=194
From [email protected] on December 28, 2010 10:40:53
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.
Attachment: DefaultValidator.java HTMLValidationRule.java ValidatorTest.java DefaultSecurityConfiguration.java
From [email protected] on December 28, 2010 13:57:57
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; } }
From [email protected] on August 09, 2012 01:46:59
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.
From [email protected] on August 09, 2012 20:25:35
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.
From [email protected] on August 17, 2012 13:38:19
+1 on getting the classpath loading fixed. These inconsistencies make it harder for folks to get the library working for eval.
From [email protected] on November 26, 2013 21:59:34
+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 "" is valid and safe HTML.
From [email protected] on January 08, 2014 11:51:56
+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.
From chrisisbeef on September 18, 2014 13:41:09
This is scheduled for v2.2
Labels: Milestone-Release2.2