Javadoc enhancements #886
There are no files selected for viewing
kwwall marked this conversation as resolved.
Show resolved
Hide resolved
|
kwwall marked this conversation as resolved.
Show resolved
Hide resolved
|
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,31 @@ | ||
| package org.owasp.esapi.errors; | ||
|
|
||
| /** | ||
| * A {@code NotConfiguredByDefaultException} should be thrown when a method that | ||
| * is disabled by default is invoked, | ||
| * </p><p> | ||
| * See the ESAPI properties "ESAPI.enableLegCannonModeAndGetMyAssFired.methodNames" and | ||
| * "ESAPI,enableLegCannonModeAndGetMyAssFired,justification" in the | ||
| * <b>ESAPI.properties</b> file for additional details. | ||
| * </p> | ||
| */ | ||
| public class NotConfiguredByDefaultException extends ConfigurationException { | ||
|
|
||
| protected static final long serialVersionUID = 1L; | ||
|
|
||
| public NotConfiguredByDefaultException(Exception e) { | ||
| super(e); | ||
| } | ||
|
|
||
| public NotConfiguredByDefaultException(String s) { | ||
| super(s); | ||
| } | ||
|
|
||
| public NotConfiguredByDefaultException(String s, Throwable cause) { | ||
| super(s, cause); | ||
| } | ||
|
|
||
| public NotConfiguredByDefaultException(Throwable cause) { | ||
| super(cause); | ||
| } | ||
| } |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -578,3 +578,37 @@ Validator.AcceptLenientDates=false | |
| # | ||
| #Validator.HtmlValidationAction=clean | ||
| Validator.HtmlValidationAction=throw | ||
|
|
||
| ######################################################################################## | ||
| # The following methods are now disabled in the default configuration and must | ||
| # be explicity enabled. If you try to invoke a method disabled by default, ESAPI | ||
| # will thrown a NotConfiguredByDefaultException. | ||
| # | ||
| # The reason for this varies, but ranges from they are not really suitable for | ||
| # enterprise scale to that are only marginally tested (if at all) versus the are | ||
| # unsafe for general use, although them may be fine when combined with other | ||
| # security-in-depth techiques. | ||
| # | ||
| # The disabled-by-default methods are: | ||
| # org.owasp.esapi.reference.DefaultEncoder.encodeForSQL | ||
| # org.owasp.esapi.ESAPI.accessController [FUTURE] | ||
| # | ||
| # The format is a comma-separated list of fully,Qualified.ClassNames.methodName | ||
| # | ||
| # Note to ESAPI Devs: There is presently no way to specific which specific | ||
| # method to indicate here when the method name alone, | ||
| # absent from its signature, is ambiguous, so it is | ||
| # best to avoid those if at all possible! | ||
| # | ||
| # An example of that would be something like: | ||
| # org.owasp.esapi.reference.DefaultValidator.getValidPrintable | ||
| # which has 4 interfaces so currently, there's no way to | ||
| # specify a specific one. | ||
| # | ||
| ESAPI.enableLegCannonModeAndGetMyAssFired.methodNames=org.owasp.esapi.reference.DefaultEncoder.encodeForSQL | ||
|
There was a problem hiding this comment. I agree with the intent, but we may want to adjust the property name before releasing to the public. I expect folks will be using this as a stop-gap to keep code from breaking as they're working through migration processes. There was a problem hiding this comment. It caught your attention didn't it? |
||
|
|
||
| # Normally you would put some text here (that will be logged) that provides some | ||
| # justification as to why you have enabled these functions. This can be | ||
| # anythuing such as a Jira or ServiceNow ticket number, a security exception | ||
| # reference, etc. If it is left empty, it will just like "Justification: none".` | ||
| ESAPI.enableLegCannonModeAndGetMyAssFired.justification=blah,blah. Please don't fire my @$$. Ticket # 12345 | ||
|
There was a problem hiding this comment. I would prefer to not allow this feature for client-specific messages in library workflows. Clients can track this however they want in their own environments. EG: There was a problem hiding this comment. We will still have our own messages and this might not want to limit it to just things that we've deprecated. But the intent here is that many companies require approval of use of dangerous and/or deprecated methods and this would allow them to provide an identifying security exception ID that InfoSec could cross reference in audit logs. I would likely log it independently rather than make it part of the exception message (which you never know, may end up being displayed to the end user, which might have been your concern). But the ESAPI's safe logging should be able to handle whatever get's thrown at it, otherwise it's not really "safe". Anyhow, that's the thought behind it. Mostly to help track in audit logging, which was @xeno6696's idea. I don;t think I can compose any sort of structure here as different companies use different things to ID long-standing security exceptions. There was a problem hiding this comment. I think for log statements, including the CVE number directly in the logs would be proper. Not sure we should push that however until we're ready to be public-public. There was a problem hiding this comment. Right; I intend to do that, but it will be hard-coded into the code, not via some property. If they want to get rid of it, they'll have to at least work a bit harder at it than just tweaking some ESAPI.properties file. |
||
Uh oh!
There was an error while loading. Please reload this page.