-
Notifications
You must be signed in to change notification settings - Fork 370
Javadoc enhancements #886
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Javadoc enhancements #886
Conversation
@xeno6696 @jeremiahjstacey @sempf @hackermatic - The Javadoc is ready to review. No code changes to this PR. |
# 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It caught your attention didn't it?
# 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer to not allow this feature for client-specific messages in library workflows.
We should have a message that is either attributed to an Exception or logged at a Warning level which states the feature that is bound for deprecation and the date which it will be removed (per deprecation policy).
Clients can track this however they want in their own environments.
EG:
encodeForSQL(Codec codec, String input) {
String deprecationMsg="ESAPI.DEPRECATION-6//9/2026 ESAPI.encodeForSQL method use should be replaced with ....blah blah blah";
if ( ! deprecationsEnabled("encodeForSQL")) {
throw new NotConfiguredByDefaultException(deprecationMsg);
} else {
log.warning(deprecationMsg);
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
* Implementation of the Codec interface for DB2 strings. This function will only protect you from SQLi in limited situations. | ||
* Implementation of the Codec interface for IBM Db2 strings. | ||
* This function will only protect you from SQLi in limited situations. | ||
* To improve your changces of success, you made also need to do some |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
may instead of "made"
* This function will only protect you from SQLi in limited situations. | ||
* To improve your changces of success, you made also need to do some | ||
* additional canonicalization and input validation first. Before using this class, | ||
* pleaes be sure to read the "SECURITY WARNING" in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please
* This function will only protect you from SQLi in limited situations. | ||
* To improve your changces of success, you made also need to do some | ||
* additional canonicalization and input validation first. Before using this class, | ||
* pleaes be sure to read the "SECURITY WARNING" in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please
* By following that advise, you will minimize the impact and/or likelihood of any | ||
* vulnerabilities from bugs in the ESAPI code or accidental misuse of the ESAPI | ||
* library on your part. In particular, whenever there are cases where cients use | ||
* any of these {@link org.owasp.esapi.codecs.Codec} classes drectly, it is highly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
directly
* </p><p> | ||
* <b>SECURITY WARNING:</b> This method is <u>NOT</u> recommended. The use of the {@code PreparedStatement} | ||
* interface is the preferred approach. However, if for some reason | ||
* this is impossible, then this method is provided as significantly weaker |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"as a significantly..."
* if you need a temporary emergency SQLi defense shield, but using {@code PreparedStatement} | ||
* is still your best option if you have the time and resources. | ||
* </p><p> | ||
* <b>Note to AppSec / Security Auditor teams:</b> If see this method being used in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"If you see this method..."
* Implementation accepts 2 Modes as identified by the OWASP Recommended | ||
* escaping strategies: | ||
* This function will only protect you from SQLi in limited situations. | ||
* To improve your changces of success, you made also need to do some |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
chances mispelled
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would request various typos be fixed prior to release. No other concerns regarding content however.
method is not explicitly enabled. Should result in a NotConfiguredByDefaultException being thrown.
I approve, just in the dentists chair and don’t have time to find the right button |
Work on fixing up some Javadoc and tweak test version of ESAPI.properties.