Skip to content

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

Merged
merged 14 commits into from
Jun 11, 2025
Merged

Javadoc enhancements #886

merged 14 commits into from
Jun 11, 2025

Conversation

kwwall
Copy link
Contributor

@kwwall kwwall commented Jun 9, 2025

Work on fixing up some Javadoc and tweak test version of ESAPI.properties.

@kwwall kwwall added the javadoc label Jun 9, 2025
@kwwall
Copy link
Contributor Author

kwwall commented Jun 9, 2025

@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
Copy link
Collaborator

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.

Copy link
Contributor Author

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
Copy link
Collaborator

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);
}

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

Copy link
Contributor Author

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

chances mispelled

Copy link
Collaborator

@xeno6696 xeno6696 left a 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.

@xeno6696 xeno6696 dismissed their stale review June 11, 2025 15:36

Completed already

@xeno6696
Copy link
Collaborator

I approve, just in the dentists chair and don’t have time to find the right button

@xeno6696 xeno6696 merged commit e232291 into ESAPI:develop Jun 11, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants