Allow certain characters to be immune for ESAPI encoder?
I am trying to incorporate the ESAPI encoder with my JavaEE application and want it to not encode a certain set of characters, for example '<', '!', '(', ')'.
I read on the documentation https://static.javadoc.io/org.owasp.esapi/esapi/2.0.1/org/owasp/esapi/Encoder.html that "all characters should be encoded, except for a specific list of "immune" characters".
I would like to know where and how I can configure this specific list of "immune" characters. Would it be in the ESAPI.properties file?
java java-ee owasp esapi
asked Nov 22 '18 at 16:58
Mingxuan HeMingxuan He
62
add a comment |
I am trying to incorporate the ESAPI encoder with my JavaEE application and want it to not encode a certain set of characters, for example '<', '!', '(', ')'.
I read on the documentation https://static.javadoc.io/org.owasp.esapi/esapi/2.0.1/org/owasp/esapi/Encoder.html that "all characters should be encoded, except for a specific list of "immune" characters".
I would like to know where and how I can configure this specific list of "immune" characters. Would it be in the ESAPI.properties file?
java java-ee owasp esapi
asked Nov 22 '18 at 16:58
Mingxuan HeMingxuan He
62
Totally agree with Kevin’s response below. Several of the characters you say you want to be immune are known characters that are used in many programming languages, and making those chars in particular immune, invites code injection to your application. What are you really trying to do that you think immunity is the answer? There’s a code smell here, and it stinks.
– avgvstvs
Nov 24 '18 at 1:22
add a comment |
I am trying to incorporate the ESAPI encoder with my JavaEE application and want it to not encode a certain set of characters, for example '<', '!', '(', ')'.
I read on the documentation https://static.javadoc.io/org.owasp.esapi/esapi/2.0.1/org/owasp/esapi/Encoder.html that "all characters should be encoded, except for a specific list of "immune" characters".
I would like to know where and how I can configure this specific list of "immune" characters. Would it be in the ESAPI.properties file?
java java-ee owasp esapi
asked Nov 22 '18 at 16:58
Mingxuan HeMingxuan He
62
I am trying to incorporate the ESAPI encoder with my JavaEE application and want it to not encode a certain set of characters, for example '<', '!', '(', ')'.
I read on the documentation https://static.javadoc.io/org.owasp.esapi/esapi/2.0.1/org/owasp/esapi/Encoder.html that "all characters should be encoded, except for a specific list of "immune" characters".
I would like to know where and how I can configure this specific list of "immune" characters. Would it be in the ESAPI.properties file?
java java-ee owasp esapi
java java-ee owasp esapi
asked Nov 22 '18 at 16:58
Mingxuan HeMingxuan He
62
asked Nov 22 '18 at 16:58
Mingxuan HeMingxuan He
62
asked Nov 22 '18 at 16:58
Mingxuan HeMingxuan He
62
asked Nov 22 '18 at 16:58
Mingxuan HeMingxuan He
62
asked Nov 22 '18 at 16:58
Mingxuan HeMingxuan He
62
62
Totally agree with Kevin’s response below. Several of the characters you say you want to be immune are known characters that are used in many programming languages, and making those chars in particular immune, invites code injection to your application. What are you really trying to do that you think immunity is the answer? There’s a code smell here, and it stinks.
– avgvstvs
Nov 24 '18 at 1:22
add a comment |
Totally agree with Kevin’s response below. Several of the characters you say you want to be immune are known characters that are used in many programming languages, and making those chars in particular immune, invites code injection to your application. What are you really trying to do that you think immunity is the answer? There’s a code smell here, and it stinks.
– avgvstvs
Nov 24 '18 at 1:22
Totally agree with Kevin’s response below. Several of the characters you say you want to be immune are known characters that are used in many programming languages, and making those chars in particular immune, invites code injection to your application. What are you really trying to do that you think immunity is the answer? There’s a code smell here, and it stinks.
– avgvstvs
Nov 24 '18 at 1:22
Totally agree with Kevin’s response below. Several of the characters you say you want to be immune are known characters that are used in many programming languages, and making those chars in particular immune, invites code injection to your application. What are you really trying to do that you think immunity is the answer? There’s a code smell here, and it stinks.
– avgvstvs
Nov 24 '18 at 1:22
add a comment |
1 Answer
1
active
oldest
votes
The simple answer is, you can't. Or at least not easily. You could do this by changing the line in ESAPI.properties from:
ESAPI.Encoder=org.owasp.esapi.reference.DefaultEncoder
to something like
ESAPI.Encoder=com.MyCompany.myApp.MyEncoder
and then in MyEncoder.java, replacing one or more of ESAPI's initializations of its various IMMUNE_* variables with your own. Butt that's the only way to do it. There is no method or property to redefine this, because in the general case, you should never want to do so. (There was a [poor, IMO] design decision to make all of ESAPI's reference implementations a singleton, so providing such a method to DefaultEncoder class would me you would be changing it for all instances of a class and that just seems too dangerous.)
So rather than answering your question like I did, I should be asking you why do you wish to do this? The IMMUNE_CSS codec recently had '#' added to in (currently only in the 'develop' branch on GitHub), but even that was not done without extensive discussion amongst current and former OWASP project leaders. The immune lists are judiciously choose to be "safe" in all know cases. Then are not intended to be applied for only some edge cases known to be safe. That is why I am asking "Why do you want to do this? What specifically are you trying to achieve?" as there may be a better approach to what you are trying to do.
answered Nov 23 '18 at 22:12
Kevin W. WallKevin W. Wall
52625
Initially, we wanted to fix our log forge method. We found the ESAPI encoder and replaced our custom encoder to the ESAPI one. But once we changed this, we realized we had a lot of hard code that used these symbols when we were logging, which I thought it'd be fine to just ignore these symbols, which is why I asked this question. We realize now that this "solution" has a pretty bad smell and we plan to entirely refactor our method of logging instead.
– Mingxuan He
Nov 25 '18 at 3:19
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53435475%2fallow-certain-characters-to-be-immune-for-esapi-encoder%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The simple answer is, you can't. Or at least not easily. You could do this by changing the line in ESAPI.properties from:
ESAPI.Encoder=org.owasp.esapi.reference.DefaultEncoder
to something like
ESAPI.Encoder=com.MyCompany.myApp.MyEncoder
and then in MyEncoder.java, replacing one or more of ESAPI's initializations of its various IMMUNE_* variables with your own. Butt that's the only way to do it. There is no method or property to redefine this, because in the general case, you should never want to do so. (There was a [poor, IMO] design decision to make all of ESAPI's reference implementations a singleton, so providing such a method to DefaultEncoder class would me you would be changing it for all instances of a class and that just seems too dangerous.)
So rather than answering your question like I did, I should be asking you why do you wish to do this? The IMMUNE_CSS codec recently had '#' added to in (currently only in the 'develop' branch on GitHub), but even that was not done without extensive discussion amongst current and former OWASP project leaders. The immune lists are judiciously choose to be "safe" in all know cases. Then are not intended to be applied for only some edge cases known to be safe. That is why I am asking "Why do you want to do this? What specifically are you trying to achieve?" as there may be a better approach to what you are trying to do.
answered Nov 23 '18 at 22:12
Kevin W. WallKevin W. Wall
52625
Initially, we wanted to fix our log forge method. We found the ESAPI encoder and replaced our custom encoder to the ESAPI one. But once we changed this, we realized we had a lot of hard code that used these symbols when we were logging, which I thought it'd be fine to just ignore these symbols, which is why I asked this question. We realize now that this "solution" has a pretty bad smell and we plan to entirely refactor our method of logging instead.
– Mingxuan He
Nov 25 '18 at 3:19
add a comment |
The simple answer is, you can't. Or at least not easily. You could do this by changing the line in ESAPI.properties from:
ESAPI.Encoder=org.owasp.esapi.reference.DefaultEncoder
to something like
ESAPI.Encoder=com.MyCompany.myApp.MyEncoder
and then in MyEncoder.java, replacing one or more of ESAPI's initializations of its various IMMUNE_* variables with your own. Butt that's the only way to do it. There is no method or property to redefine this, because in the general case, you should never want to do so. (There was a [poor, IMO] design decision to make all of ESAPI's reference implementations a singleton, so providing such a method to DefaultEncoder class would me you would be changing it for all instances of a class and that just seems too dangerous.)
So rather than answering your question like I did, I should be asking you why do you wish to do this? The IMMUNE_CSS codec recently had '#' added to in (currently only in the 'develop' branch on GitHub), but even that was not done without extensive discussion amongst current and former OWASP project leaders. The immune lists are judiciously choose to be "safe" in all know cases. Then are not intended to be applied for only some edge cases known to be safe. That is why I am asking "Why do you want to do this? What specifically are you trying to achieve?" as there may be a better approach to what you are trying to do.
answered Nov 23 '18 at 22:12
Kevin W. WallKevin W. Wall
52625
Initially, we wanted to fix our log forge method. We found the ESAPI encoder and replaced our custom encoder to the ESAPI one. But once we changed this, we realized we had a lot of hard code that used these symbols when we were logging, which I thought it'd be fine to just ignore these symbols, which is why I asked this question. We realize now that this "solution" has a pretty bad smell and we plan to entirely refactor our method of logging instead.
– Mingxuan He
Nov 25 '18 at 3:19
add a comment |
The simple answer is, you can't. Or at least not easily. You could do this by changing the line in ESAPI.properties from:
ESAPI.Encoder=org.owasp.esapi.reference.DefaultEncoder
to something like
ESAPI.Encoder=com.MyCompany.myApp.MyEncoder
and then in MyEncoder.java, replacing one or more of ESAPI's initializations of its various IMMUNE_* variables with your own. Butt that's the only way to do it. There is no method or property to redefine this, because in the general case, you should never want to do so. (There was a [poor, IMO] design decision to make all of ESAPI's reference implementations a singleton, so providing such a method to DefaultEncoder class would me you would be changing it for all instances of a class and that just seems too dangerous.)
So rather than answering your question like I did, I should be asking you why do you wish to do this? The IMMUNE_CSS codec recently had '#' added to in (currently only in the 'develop' branch on GitHub), but even that was not done without extensive discussion amongst current and former OWASP project leaders. The immune lists are judiciously choose to be "safe" in all know cases. Then are not intended to be applied for only some edge cases known to be safe. That is why I am asking "Why do you want to do this? What specifically are you trying to achieve?" as there may be a better approach to what you are trying to do.
answered Nov 23 '18 at 22:12
Kevin W. WallKevin W. Wall
52625
The simple answer is, you can't. Or at least not easily. You could do this by changing the line in ESAPI.properties from:
ESAPI.Encoder=org.owasp.esapi.reference.DefaultEncoder
to something like
ESAPI.Encoder=com.MyCompany.myApp.MyEncoder
and then in MyEncoder.java, replacing one or more of ESAPI's initializations of its various IMMUNE_* variables with your own. Butt that's the only way to do it. There is no method or property to redefine this, because in the general case, you should never want to do so. (There was a [poor, IMO] design decision to make all of ESAPI's reference implementations a singleton, so providing such a method to DefaultEncoder class would me you would be changing it for all instances of a class and that just seems too dangerous.)
So rather than answering your question like I did, I should be asking you why do you wish to do this? The IMMUNE_CSS codec recently had '#' added to in (currently only in the 'develop' branch on GitHub), but even that was not done without extensive discussion amongst current and former OWASP project leaders. The immune lists are judiciously choose to be "safe" in all know cases. Then are not intended to be applied for only some edge cases known to be safe. That is why I am asking "Why do you want to do this? What specifically are you trying to achieve?" as there may be a better approach to what you are trying to do.
answered Nov 23 '18 at 22:12
Kevin W. WallKevin W. Wall
52625
answered Nov 23 '18 at 22:12
Kevin W. WallKevin W. Wall
52625
answered Nov 23 '18 at 22:12
Kevin W. WallKevin W. Wall
52625
answered Nov 23 '18 at 22:12
Kevin W. WallKevin W. Wall
52625
52625
Initially, we wanted to fix our log forge method. We found the ESAPI encoder and replaced our custom encoder to the ESAPI one. But once we changed this, we realized we had a lot of hard code that used these symbols when we were logging, which I thought it'd be fine to just ignore these symbols, which is why I asked this question. We realize now that this "solution" has a pretty bad smell and we plan to entirely refactor our method of logging instead.
– Mingxuan He
Nov 25 '18 at 3:19
add a comment |
Initially, we wanted to fix our log forge method. We found the ESAPI encoder and replaced our custom encoder to the ESAPI one. But once we changed this, we realized we had a lot of hard code that used these symbols when we were logging, which I thought it'd be fine to just ignore these symbols, which is why I asked this question. We realize now that this "solution" has a pretty bad smell and we plan to entirely refactor our method of logging instead.
– Mingxuan He
Nov 25 '18 at 3:19
Initially, we wanted to fix our log forge method. We found the ESAPI encoder and replaced our custom encoder to the ESAPI one. But once we changed this, we realized we had a lot of hard code that used these symbols when we were logging, which I thought it'd be fine to just ignore these symbols, which is why I asked this question. We realize now that this "solution" has a pretty bad smell and we plan to entirely refactor our method of logging instead.
– Mingxuan He
Nov 25 '18 at 3:19
Initially, we wanted to fix our log forge method. We found the ESAPI encoder and replaced our custom encoder to the ESAPI one. But once we changed this, we realized we had a lot of hard code that used these symbols when we were logging, which I thought it'd be fine to just ignore these symbols, which is why I asked this question. We realize now that this "solution" has a pretty bad smell and we plan to entirely refactor our method of logging instead.
– Mingxuan He
Nov 25 '18 at 3:19
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53435475%2fallow-certain-characters-to-be-immune-for-esapi-encoder%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Totally agree with Kevin’s response below. Several of the characters you say you want to be immune are known characters that are used in many programming languages, and making those chars in particular immune, invites code injection to your application. What are you really trying to do that you think immunity is the answer? There’s a code smell here, and it stinks.
– avgvstvs
Nov 24 '18 at 1:22