Encoding

[Jim Manico <ji...@owasp.org>]

Shiro,

What a fantastic project. I applaud your efforts!

I would like to suggest that Shiro implements an encoding library to 
stop injection attacks.

Specific to Cross Site Scripting: encodeForHTML, encodeForHTMLAttribute, 
encodeForJavaScriptVariable, encodeForCSSValue, etc.
Specific to Command Injection: encodeForOS, etc.

Etc.

Does this interest the project in any way?

PS: Apache probably also needs an encoding-commons, I dare say.

Does this sound interesting or appropriate?

Aloha,

-- 
Jim Manico

Connections Committee Chair
Cheatsheet Series Product Manager
OWASP Podcast Producer/Host

jim@owasp.org
www.owasp.org

Re: Encoding

[Jim Manico <ji...@owasp.org>]

Les,

Pleasure to meet you!

I basically want to port the ESAPI project's encoder (It's BSD so 
licensing issues should not be a problem) over to Shiro to some degree. 
And if not the code, at least the concepts.

I think we need to start with XSS defense. It's the most common type of 
injection and is also the most complex to stop.

Take a look at:

http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Encoder.html
http://download.microsoft.com/download/E/B/4/EB46CC8E-9A96-4ED0-AA37-E941DA0F8598/AntiXSS%20v4.2.docx

Also read

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/Abridged_XSS_Prevention_Cheat_Sheet

.NET did get this very right, I hate to admit. :)

For starters we need (and of course we may need to rename these in the 
Shiro way): All should just take one string argument.

1) encodeForHTML
2) encodeForHTMLAttribute
3) encodeForJavaScriptVariable
4) encodeForCSSValue <- still dangerous due to CSS Expressions that pop 
even when encoded in ie 6/7
5) encodeForURLGetParameter
6) encodeForXML
7) encoderForXMLAttribute
8) htmlSanitizer <- to stop XSS when dev's use WYSIWYG like TinyMCE. 
This is a brutally complex use case.

I think 1-7 will be fairly easy. 8 is brutal and we may want to borrow 
code such as 
https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project - the 
author is good egg and I'm sure we will be ok with this. (Mike Samuel 
from Google, very sharp).

Just throwing ideas out. What do you think is best for Shiro?

Aloha,
Jim Manico

> Hi Jim,
>
> Aloha! E komo mai! Welcome to the Shiro community.  And thanks for the
> kudos - it's nice to see you drop in!
>
>> I would like to suggest that Shiro implements an encoding library to stop
>> injection attacks.
>>
>> Specific to Cross Site Scripting: encodeForHTML, encodeForHTMLAttribute,
>> encodeForJavaScriptVariable, encodeForCSSValue, etc.
>> Specific to Command Injection: encodeForOS, etc.
>>
>> Etc.
>>
>> Does this interest the project in any way?
> I'm extremely interested in this as an effort.  There is a
> org.apache.shiro.codec package that can certainly stand to be flushed
> out, or maybe this is worthy of another package/module.
>
>> PS: Apache probably also needs an encoding-commons, I dare say.
>>
>> Does this sound interesting or appropriate?
> Most definitely!
>
> How would you envision this being implemented?  Any architectural
> overview that you might be able to present?  Module organization, etc?
>
> Best regards,
>
> Les

Re: Encoding

[Les Hazlewood <lh...@apache.org>]

Hi Jim,

Aloha! E komo mai! Welcome to the Shiro community.  And thanks for the
kudos - it's nice to see you drop in!

> I would like to suggest that Shiro implements an encoding library to stop
> injection attacks.
>
> Specific to Cross Site Scripting: encodeForHTML, encodeForHTMLAttribute,
> encodeForJavaScriptVariable, encodeForCSSValue, etc.
> Specific to Command Injection: encodeForOS, etc.
>
> Etc.
>
> Does this interest the project in any way?

I'm extremely interested in this as an effort.  There is a
org.apache.shiro.codec package that can certainly stand to be flushed
out, or maybe this is worthy of another package/module.

> PS: Apache probably also needs an encoding-commons, I dare say.
>
> Does this sound interesting or appropriate?

Most definitely!

How would you envision this being implemented?  Any architectural
overview that you might be able to present?  Module organization, etc?

Best regards,

Les