OWASP - User contributions [en]

Project Information:template OpenSign Server Project - Final Review - First Reviewer - D

2009-02-27T11:06:33Z

Pparrend:

[[Project Information:template OpenSign Server Project|Clik here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''FINAL REVIEW'''
|-
| style="width:25%; background:white" align="center"|'''PART I'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Project Deliveries & Objectives
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Summer of Code 2008 Applications#Online code signing and integrity verification service for open source community (OpenSign Server)|OWASP OpenSign Server Project's Deliveries & Objectives]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications#Online code signing and integrity verification service for open source community (OpenSign Server)|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|

* Client tool to generate RSA key pair and request signing certificate by return via a secure connection, secure connection will authenticate user after a dedicated registration process and also use mutual authentication SSL to avoid man-in-the-middle - returning certificate to user in real time. Registered developer can then submit their SPC online to verify the SPC.

-> ok

* Client tool to download software that will do a proper verification on the software against the code signing service

-> code download and verification is not available in the OSSJClient. Verification of the certificate is therefore performed
independently of the signed code (one step is missing in the process).

* Website interface for the code signing service

-> ok

* Set of Admin tools to manage the code signing service, user and certificate repository

-> available, but completeness of features should be validated

* Documentation

-> User documentation has been completed.

-> The demonstration could be more explicit related to the integration of the tools in the software deployment process.
The role of entities (certificate, CSR) could be explained more precisely, so as to enable developpers with limited
security knowledge to use the tool. For instance: integrate the documentation (opendsign-concept.doc ...) in the
demo slides.

Documentation in the code repository contains the original design doc rather than the current dev/use documentation.

|-
| style="width:25%; background:#7B8ABD" align="center"|
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications#Online code signing and integrity verification service for open source community (OpenSign Server)|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|

'''NOTE''': the deliverables are tagged in the project definition as 'idealized result', and were since the beginning identified
as an ambitious goal. The project delivers running tools and documentation, which do not fullfil these expectations,
but provide developpers with usefull and simple to use tools. The percentage are relative to the original definition.

* Client tool to generate RSA key pair and request signing certificate by return via a secure connection, secure connection will authenticate user after a dedicated registration process and also use mutual authentication SSL to avoid man-in-the-middle - returning certificate to user in real time. Registered developer can then submit their SPC online to verify the SPC.

100 %

* Client tool to download software that will do a proper verification on the software against the code signing service

50%

* Website interface for the code signing service
90 %

* Set of Admin tools to manage the code signing service, user and certificate repository

70 %

|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
'''First comments''':

* it would be nice it it would be possible to simply download and run the code
for the server and the client (I have made some tests under linux, this seems not to be the case for the latter releases available on the project web page)
* available scripts for starting both under MS win & linux, with default config
* available user documentation: what can I do with each tool, how (for instance under the form of a '5 minutes introduction' and reference list of available functions) ?
* is the C# code available for download and execution ?
* it would be nice if the 'trunk' would be documented in a way that let the user know:
- how to compile everything (without needing to install libraries from the web) ?

- how to run the server and clients (a global 'readme' file is missing).

* Moreover, the 'opensign-design' document could be completed. User documentation mqkes this less urgent.

'''Final Review'''

Extending the OSSJClient with code download and verification feature would provide a important added value for
a reasonnable work overhead. It could therefore be done in priority.

Please see other omments for further remarks.

|-
| style="width:25%; background:white" align="center"|'''PART II'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Assessment Criteria
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None (validated in previous review).
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
* Add a common About Box or help menu in the tool itself
o (which lists name of tool, author, e-mail address of author, current version number and/or release date)

Help is provided. Informations related to the authors are not.
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
* Be reasonably easy to use

-> OK

* Include online documention built into tool (based on required user documentation)

-> User documentation is made available.

* Include build scripts that facilitate building the application from source (Goal: One-click build)

-> Completeness to be checked. Currently build tools are dependent of development environment (maven for Java; these environments
should be specified).

* Publicly accessible bug tracking system established, ideally at the same place as the source code repository (e.g., at Google code, or Sourceforge)

-> TODO, as far as I know

* Be run through Fortify Software's open source review (if appropriate) and FindBugs.

-> TODO, or include reports

* C/C++ apps (if we have any) should consider being run through Coverity's open source review. Coverity also accepts submissions for open source Java applications.

-> TODO, or include reports

* When approved to be Release Quality: Update the link to it on: the OWASP Project page and update its project quality tag on its project page to be Release Quality.

'''Recommendations''':

* Conference style Powerpoint presentation that describes the use and status of the tool. (This could be used by others to discuss the tool at OWASP Chapter meetings, serve as easy to review offline documentation, etc.)

-> available

* UAT pass on functionality of the tool

-> TODO

* Developer documents any limitations

-> Roadmap for future development is provided.

|-
| style="width:25%; background:#7B8ABD" align="center"|
4. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
* Documentation update has been performed.
|}

Category:OWASP OpenSign Server Project - Assessment Frame

2009-02-08T16:25:53Z

Pparrend:

[[:Category:OWASP OpenSign Server Project|Click here to return to project's main page]].
{| style="width:100%" border="0" align="center"
! colspan="2" align="center" style="background:#4058A0; color:white"|'''PROJECT IDENTIFICATION'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Project Name'''
| colspan="1" style="width:85%; background:#cccccc" align="left"|'''OWASP OpenSign Server Project (Online code signing and integrity verification service for open source community)'''
|}
{| style="width:100%" border="0" align="center"
! colspan="5" align="center" style="background:#4058A0; color:white"|ASSESSMENT AND REVIEW PROCESS - OWASP Summer of Code 2008
|-
| style="width:15%; background:#6C82B5" align="center"|'''Reviewer'''
| style="width:21%; background:#b3b3b3" align="center"|'''Author's Self Evaluation''' [[User:Philipp Potisk|'''Philipp Potisk''']] [mailto:techierebel@yahoo.co.uk Richard Conway]
| style="width:21%; background:#b3b3b3" align="center"|'''First Reviewer''' [[:User:Pparrend|'''Pierre Parrend''']]
| style="width:21%; background:#b3b3b3" align="center"|'''Second Reviewer''' [[:User:Gary.m.burns|'''Gary Burns''']]
| style="width:22%; background:#b3b3b3" align="center"|'''OWASP Board Member''' Non applicable
|-
| style="width:15%; background:#7B8ABD" align="center"|'''50% Review'''
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes''' --------- [[Project Information:template OpenSign Server Project - 50 Review - Self Evaluation - A|Self-Evaluation (A)]]
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes''' --------- [[Project Information:template OpenSign Server Project - 50 Review - First Reviewer - C|First Reviewer (C)]]
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes''' --------- [[Project Information:template OpenSign Server Project 50 Review Second Review E|Second Reviewer (E)]]
| style="width:22%; background:#C2C2C2" align="center"|X
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Final Review'''
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes/No''' (To update) --------- Which status has been reached? '''Season of Code''' - (To update) --------- [[Project Information:template OpenSign Server Project - Final Review - Self Evaluation - B|Self-Evaluation (B)]]
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes/No''' (To update) --------- Which status has been reached? '''Beta Quality''' --------- [[Project Information:template OpenSign Server Project - Final Review - First Reviewer - D|First Reviewer (D)]]
| style="width:21%; background:#C2C2C2" align="center"|Objectives & Deliveries reached? '''Yes''' --------- Which status has been reached? '''Beta Quality''' --------- [[Project Information:template OpenSign Server Project - Final Review - Second Reviewer - F|Second Reviewer (F)]]
| style="width:22%; background:#C2C2C2" align="center"|X
|}

Project Information:template OpenSign Server Project - Final Review - First Reviewer - D

2009-02-08T14:29:37Z

Pparrend:

[[Project Information:template OpenSign Server Project|Clik here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''FINAL REVIEW'''
|-
| style="width:25%; background:white" align="center"|'''PART I'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Project Deliveries & Objectives
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Summer of Code 2008 Applications#Online code signing and integrity verification service for open source community (OpenSign Server)|OWASP OpenSign Server Project's Deliveries & Objectives]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications#Online code signing and integrity verification service for open source community (OpenSign Server)|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|

* Client tool to generate RSA key pair and request signing certificate by return via a secure connection, secure connection will authenticate user after a dedicated registration process and also use mutual authentication SSL to avoid man-in-the-middle - returning certificate to user in real time. Registered developer can then submit their SPC online to verify the SPC.

-> ok

* Client tool to download software that will do a proper verification on the software against the code signing service

-> code download and verification is not available in the OSSJClient. Verification of the certificate is therefore performed
independently of the signed code (one step is missing in the process).

* Website interface for the code signing service

-> ok

* Set of Admin tools to manage the code signing service, user and certificate repository

-> available, but completeness of features should be validated

* Documentation

-> The demonstration could be more explicit related to the integration of the tools in the software deployment process.
The role of entities (certificate, CSR) could be explained more precisely, so as to enable developpers with limited
security knowledge to use the tool. For instance: integrate the documentation (opendsign-concept.doc ...) in the
demo slides.

Documentation in the code repository contains the original design doc rather than the current dev/use documentation.

|-
| style="width:25%; background:#7B8ABD" align="center"|
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications#Online code signing and integrity verification service for open source community (OpenSign Server)|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|

'''NOTE''': the deliverables are tagged in the project definition as 'idealized result', and were since the beginning identified
as an ambitious goal. The project delivers running tools and documentation, which do not fullfil these expectations,
but provide developpers with usefull and simple to use tools. The percentage are relative to the original definition.

* Client tool to generate RSA key pair and request signing certificate by return via a secure connection, secure connection will authenticate user after a dedicated registration process and also use mutual authentication SSL to avoid man-in-the-middle - returning certificate to user in real time. Registered developer can then submit their SPC online to verify the SPC.

100 %

* Client tool to download software that will do a proper verification on the software against the code signing service

50%

* Website interface for the code signing service
90 %

* Set of Admin tools to manage the code signing service, user and certificate repository

70 %

|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
'''First comments''':

* it would be nice it it would be possible to simply download and run the code
for the server and the client (I have made some tests under linux, this seems not to be the case for the latter releases available on the project web page)
* available scripts for starting both under MS win & linux, with default config
* available user documentation: what can I do with each tool, how (for instance under the form of a '5 minutes introduction' and reference list of available functions) ?
* is the C# code available for download and execution ?
* it would be nice if the 'trunk' would be documented in a way that let the user know:
- how to compile everything (without needing to install libraries from the web) ?

- how to run the server and clients (a global 'readme' file is missing).

* Moreover, the 'opensign-design' document could be completed.

'''Final Review'''

Extending the OSSJClient with code download and verification feature would provide a important added value for
a reasonnable work overhead. It could therefore be done in priority.

Please see other omments for further remarks.

|-
| style="width:25%; background:white" align="center"|'''PART II'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Assessment Criteria
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None (validated in previous review).
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
* Add a common About Box or help menu in the tool itself
o (which lists name of tool, author, e-mail address of author, current version number and/or release date)

Help is provided. Informations related to the authors are not.
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
* Be reasonably easy to use

-> OK

* Include online documention built into tool (based on required user documentation)

-> should still be integrated.

* Include build scripts that facilitate building the application from source (Goal: One-click build)

-> Completeness to be checked. Currently build tools are dependent of development environment (maven for Java; these environments
should be specified).

* Publicly accessible bug tracking system established, ideally at the same place as the source code repository (e.g., at Google code, or Sourceforge)

-> TODO, as far as I know

* Be run through Fortify Software's open source review (if appropriate) and FindBugs.

-> TODO, or include reports

* C/C++ apps (if we have any) should consider being run through Coverity's open source review. Coverity also accepts submissions for open source Java applications.

-> TODO, or include reports

* When approved to be Release Quality: Update the link to it on: the OWASP Project page and update its project quality tag on its project page to be Release Quality.

'''Recommendations''':

* Conference style Powerpoint presentation that describes the use and status of the tool. (This could be used by others to discuss the tool at OWASP Chapter meetings, serve as easy to review offline documentation, etc.)

-> available

* UAT pass on functionality of the tool

-> TODO

* Developer documents any limitations

-> TODO

|-
| style="width:25%; background:#7B8ABD" align="center"|
4. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
* Documentation update could be done to adapt original design to current development status
|}

Project Information:template OpenSign Server Project - Final Review - First Reviewer - D

2009-02-08T14:25:32Z

Pparrend:

[[Project Information:template OpenSign Server Project|Clik here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''FINAL REVIEW'''
|-
| style="width:25%; background:white" align="center"|'''PART I'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Project Deliveries & Objectives
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Summer of Code 2008 Applications#Online code signing and integrity verification service for open source community (OpenSign Server)|OWASP OpenSign Server Project's Deliveries & Objectives]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications#Online code signing and integrity verification service for open source community (OpenSign Server)|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|

* Client tool to generate RSA key pair and request signing certificate by return via a secure connection, secure connection will authenticate user after a dedicated registration process and also use mutual authentication SSL to avoid man-in-the-middle - returning certificate to user in real time. Registered developer can then submit their SPC online to verify the SPC.

-> ok

* Client tool to download software that will do a proper verification on the software against the code signing service

-> code download and verification is not available in the OSSJClient. Verification of the certificate is therefore performed
independently of the signed code (one step is missing in the process).

* Website interface for the code signing service

-> ok

* Set of Admin tools to manage the code signing service, user and certificate repository

-> available, but completeness of features should be validated

* Documentation

-> The demonstration could be more explicit related to the integration of the tools in the software deployment process.
The role of entities (certificate, CSR) could be explained more precisely, so as to enable developpers with limited
security knowledge to use the tool. For instance: integrate the documentation (opendsign-concept.doc ...) in the
demo slides.

Documentation in the code repository contains the original design doc rather than the current dev/use documentation.

|-
| style="width:25%; background:#7B8ABD" align="center"|
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications#Online code signing and integrity verification service for open source community (OpenSign Server)|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|

'''NOTE''': the deliverables are tagged in the project definition as 'idealized result', and were since the beginning identified
as an ambitious goal. The project delivers running tools and documentation, which do not fullfil these expectations,
but provide developpers with usefull and simple to use tools. The percentage are relative to the original definition.

* Client tool to generate RSA key pair and request signing certificate by return via a secure connection, secure connection will authenticate user after a dedicated registration process and also use mutual authentication SSL to avoid man-in-the-middle - returning certificate to user in real time. Registered developer can then submit their SPC online to verify the SPC.

100 %

* Client tool to download software that will do a proper verification on the software against the code signing service

50%

* Website interface for the code signing service
90 %

* Set of Admin tools to manage the code signing service, user and certificate repository

70 %

|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
'''First comments''':

* it would be nice it it would be possible to simply download and run the code
for the server and the client (I have made some tests under linux, this seems not to be the case for the latter releases available on the project web page)
* available scripts for starting both under MS win & linux, with default config
* available user documentation: what can I do with each tool, how (for instance under the form of a '5 minutes introduction' and reference list of available functions) ?
* is the C# code available for download and execution ?
* it would be nice if the 'trunk' would be documented in a way that let the user know:
- how to compile everything (without needing to install libraries from the web) ?

- how to run the server and clients (a global 'readme' file is missing).

* Moreover, the 'opensign-design' document could be completed.

|-
| style="width:25%; background:white" align="center"|'''PART II'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Assessment Criteria
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
4. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|}

Project Information:template Application Security Verification Standard - Final Review - Second Reviewer - F

2008-12-14T16:25:07Z

Pparrend:

[[Project Information:template Application Security Verification Standard|Clik here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''FINAL REVIEW'''
|-
| style="width:25%; background:white" align="center"|'''PART I'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Project Deliveries & Objectives
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Summer of Code 2008 Applications#OWASP Application Security Verification Standard|OWASP Application Security Verification Standard Project's Deliveries & Objectives]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications#OWASP Application Security Verification Standard|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
'''The opportunity, challenges, issues or need your proposal addresses'''

OWASP is looking for a commercially-workable open standard for performing application security verification efforts. The problem is that there is a huge range in the coverage and level of rigor available in the market, and consumers have no way to tell the difference between someone just running a grep tool, and someone doing painstaking code review and manual testing. So, a standard is needed.

''Comment: The draft proposes a standard of high quality which is adequate and suitable for use in commercial projects''.

'''Objectives or ways in which you will meet the goal(s)'''

The applicant’s proposal will address the above challenges as follows:
The applicant will define an evaluation framework that may be used to conduct OWASP Application Security Verification Standard certifications.
The applicant will define an OWASP Application Security Verification Standard which defines levels that applications may be certified against.

''Comments: Those goals are met''.

'''Long-term vision for the project'''

The long-term vision for the project is to normalize the range in the coverage and level of rigor available in the market when it comes to performing application security verification.

''Comments: The ASVS Draft proposes a comprehensive document which can fully play this role and be a support for making this vision a reality. The actual fullfillment of the vision will depend on the dissemination of the work and of its actual efficiency for web application projects''.

|-
| style="width:25%; background:#7B8ABD" align="center"|
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications#OWASP Application Security Verification Standard|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
'''The opportunity, challenges, issues or need your proposal addresses'''

100%

'''Objectives or ways in which you will meet the goal(s)'''

100%

'''Long-term vision for the project'''

50% (Dissemination would be the remaining 50%, and do not pertain to the OWASP Summer of Code time frame).
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[https://www.owasp.org/images/7/78/Remarks_pparrend_2008_10_20.doc Comments on the ASVS Draft, 2008/10/20 ]]
|-
| style="width:25%; background:white" align="center"|'''PART II'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Assessment Criteria
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|

None.
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None

* The Beta version of the OWASP Application Security Verification Standard 2008 – Web Application Edition, should comply with following quality criteria according to the OWASP Project Assessment guidelines:

- All Alpha Quality Requirements

''Have been asserted in the first review round.''

- The document seems sufficiently or substantially complete with respect to the topic or process it is intended to cover.

''It is. The remarks from my previous comments are solved.''

- All wiki content has been reviewed by a technical editor to ensure that English grammar is correct, understandable, and the content flows well.
''OK. No particular comment, the online documentation is of quality.''

- Clear efforts to interlink this document to other appropriate Beta and Release Quality OWASP Documentation and Tools projects have been made.

'' OK (reference to the Owasp Top Ten, etc.)''

* When approved to be Beta Quality: Update the link to it on: the OWASP Project page and update its project quality tag on its project page to be Beta.

''OK.''

|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|

Following aspects are to be checked:

- Compliance to the Owasp Writing Style

- Availability at the OWASP Lulu Bookstore

- Maybe experience reports with the ASVS would be a plus to validate it or decide to bring still further improvements to the ASVS Standard Beta Quality Draft before releasing it as a 'Release Quality' document.

|-
| style="width:25%; background:#7B8ABD" align="center"|
4. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
None.
|}

Project Information:template Application Security Verification Standard - Final Review - Second Reviewer - F

2008-12-14T16:20:31Z

Pparrend:

[[Project Information:template Application Security Verification Standard|Clik here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''FINAL REVIEW'''
|-
| style="width:25%; background:white" align="center"|'''PART I'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Project Deliveries & Objectives
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Summer of Code 2008 Applications#OWASP Application Security Verification Standard|OWASP Application Security Verification Standard Project's Deliveries & Objectives]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications#OWASP Application Security Verification Standard|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
'''The opportunity, challenges, issues or need your proposal addresses'''

OWASP is looking for a commercially-workable open standard for performing application security verification efforts. The problem is that there is a huge range in the coverage and level of rigor available in the market, and consumers have no way to tell the difference between someone just running a grep tool, and someone doing painstaking code review and manual testing. So, a standard is needed.

''Comment: The draft proposes a standard of high quality which is adequate and suitable for use in commercial projects''.

'''Objectives or ways in which you will meet the goal(s)'''

The applicant’s proposal will address the above challenges as follows:
The applicant will define an evaluation framework that may be used to conduct OWASP Application Security Verification Standard certifications.
The applicant will define an OWASP Application Security Verification Standard which defines levels that applications may be certified against.

''Comments: Those goals are met''.

'''Long-term vision for the project'''

The long-term vision for the project is to normalize the range in the coverage and level of rigor available in the market when it comes to performing application security verification.

''Comments: The ASVS Draft proposes a comprehensive document which can fully play this role and be a support for making this vision a reality. The actual fullfillment of the vision will depend on the dissemination of the work and of its actual efficiency for web application projects''.

|-
| style="width:25%; background:#7B8ABD" align="center"|
2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications#OWASP Application Security Verification Standard|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
'''The opportunity, challenges, issues or need your proposal addresses'''

100%

'''Objectives or ways in which you will meet the goal(s)'''

100%

'''Long-term vision for the project'''

50% (Dissemination would be the remaining 50%, and do not pertain to the OWASP Summer of Code time frame).
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[https://www.owasp.org/images/7/78/Remarks_pparrend_2008_10_20.doc Comments on the ASVS Draft, 2008/10/20 ]]
|-
| style="width:25%; background:white" align="center"|'''PART II'''
| colspan="2" style="width:75%; background:white" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
Assessment Criteria
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[:Category:OWASP Project Assessment|OWASP Project Assessment Criteria]]
|-
| style="width:25%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Alpha Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
2. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Beta Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Having into consideration the [[:Category:OWASP Project Assessment|OWASP Project Assessment Methodology]] which criteria, if any, haven’t been fulfilled in terms of '''Release Quality''' status?
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|-
| style="width:25%; background:#7B8ABD" align="center"|
4. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
|}

Project Information:template OpenSign Server Project - Final Review - First Reviewer - D

2008-10-26T11:59:54Z

Pparrend:

Project Information:template Application Security Verification Standard - Final Review - Second Reviewer - F

2008-10-26T11:23:04Z

Pparrend:

File:Remarks pparrend 2008 10 20.doc

2008-10-26T11:20:27Z

Pparrend: Comments about the OWASP ASVS alpha release draft, on 2008_10_20.

Comments about the OWASP ASVS alpha release draft, on 2008_10_20.

Project Information:template OpenSign Server Project - 50 Review - First Reviewer - C

2008-08-28T05:26:58Z

Pparrend:

[[Project Information:template OpenSign Server Project|Click here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''50% REVIEW PROCESS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
Project Deliveries & Objectives
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Summer of Code 2008 Applications#Online code signing and integrity verification service for open source community (OpenSign Server)|OWASP OpenSign Server Project's Deliveries & Objectives]]
|-
| style="width:25x%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications#Online code signing and integrity verification service for open source community (OpenSign Server)|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|

'''Alpha Quality for Tools'''

* Agree to OWASP's open source license

OK

* The "main" page for any OWASP tool must be on the OWASP website.

OK

* This page must:
o describe the tool, the project leader, contact info, and include all relevant links, including a download link for the code and the executable version,

OK

o includes a roadmap/guideline pointing out the steps to achieve the purpose of project.

OK

o include the Alpha Quality Tool project tag. (Which we still need to define),
WHEN ACHIEVED

o be placed at OWASP Project page.

OK

* Have its code and any documentation in Googlecode, or Sourceforge.

OK

* Mailing list for project created.

OK

* Solves a core application security need.

OK since selected for the OWASP SoC

'''What has been done by the authors'''

* documents:

server concept and architecture : to be completed, Alpha quality OK

* implementation:

draft of the welcome page of the OpenSign Server Web Interface.

code structure

'''Summary'''

* The criteria for alpha quality of the OpenSign Projects have been met before the 2008.07.15

|-
| style="width:25%; background:#7B8ABD" align="center"|

2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications#Online code signing and integrity verification service for open source community (OpenSign Server)|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|

Alpha Quality: 100 %.

Overall project: 50 %

Software development: 30 %

|-
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
Document sent to the authors, 1. week of July [https://www.owasp.org/images/5/51/Review_opensign_pparrend_2008_07_04.doc]
|}

Project Information:template Application Security Verification Standard 50 Review Second Review E

2008-08-26T15:26:06Z

Pparrend:

[[Project Information:template Application Security Verification Standard|Click here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''50% REVIEW PROCESS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
Project Deliveries & Objectives
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Summer of Code 2008 Applications#OWASP Application Security Verification Standard|OWASP Application Security Verification Standard Project's Deliveries & Objectives]]
|-
| style="width:25x%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications#OWASP Application Security Verification Standard|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|

'''Alpha quality for documents'''

* Agree to OWASP's open source license
OK: Attribution ShareAlike 2.5

* The "main" page for any OWASP documentation project must be on the OWASP website. This page must:

o describe the purpose and scope of project, the project leader, contact info, and include all relevant links,

OK

o includes a roadmap/guideline pointing out the steps to achieve the purpose of project.

Not on the page

o includes a list of contributors, if a team effort.

Does not apply

o include the Alpha Quality Tool project tag. (Which we still need to define),

o be placed at OWASP Project page.

OK

* Have all its content stored in the OWASP wiki.

OK

* Mailing list for project created.

OK

* Solves a core application security documentation/process need.

Selected for the Owasp SOC 2008 for this reason.

'''What has been done by the author'''

First version of the ASVS document, with a complete summary, a complete presentation of the overall presentation process and a half of the document sections that are written.

'''Summary'''

Next objectives of the author:

- Address comments on draft delivered 29th June as they are received.

- Start and complete work on remaining documents/sections.

- Address comments on remaining documents/sections as they are received.

- Update OWASAP web site project page with status (on 15th September).

- Update OWASAP web site project page with beta drafts (on 15th September).

- Develop and discuss with OWASP a proposal to select a beta candidate application developer and to conduct a trial certification.

|-
| style="width:25%; background:#7B8ABD" align="center"|

2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications#OWASP Application Security Verification Standard|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
Alpha quality for Document: 100 % (up to an explicit roadmap, which does not seem necessary for a single document project with one single contributor)

Final document: 50 %
|-
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
Document sent to the author in the 1. week of July:
[https://www.owasp.org/images/f/f0/Review_ASVS_pparrend_2008_07_05.doc]
|}

File:Review ASVS pparrend 2008 07 05.doc

2008-08-26T15:17:20Z

Pparrend: Review document that has been transfered to the project author in the first week of July

Review document that has been transfered to the project author in the first week of July

Project Information:template OpenSign Server Project - 50 Review - First Reviewer - C

2008-08-26T15:16:13Z

Pparrend:

[[Project Information:template OpenSign Server Project|Click here to return to the previous page]].

{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''50% REVIEW PROCESS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
Project Deliveries & Objectives
| colspan="2" style="width:75%; background:#cccccc" align="left"|
[[OWASP Summer of Code 2008 Applications#Online code signing and integrity verification service for open source community (OpenSign Server)|OWASP OpenSign Server Project's Deliveries & Objectives]]
|-
| style="width:25x%; background:#4058A0" align="center"|'''QUESTIONS'''
| colspan="2" style="width:75%; background:#4058A0" align="left"|'''ANSWERS'''
|-
| style="width:25%; background:#7B8ABD" align="center"|
1. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications#Online code signing and integrity verification service for open source community (OpenSign Server)|'''the assumed ones''']], please exemplify writing down those of them that haven't been realised.
| colspan="2" style="width:75%; background:#cccccc" align="left"|

'''Alpha Quality for Tools'''

* Agree to OWASP's open source license

OK

* The "main" page for any OWASP tool must be on the OWASP website.

OK

* This page must:
o describe the tool, the project leader, contact info, and include all relevant links, including a download link for the code and the executable version,

OK

o includes a roadmap/guideline pointing out the steps to achieve the purpose of project.

OK

o include the Alpha Quality Tool project tag. (Which we still need to define),
WHEN ACHIEVED

o be placed at OWASP Project page.

OK

* Have its code and any documentation in Googlecode, or Sourceforge.

OK

* Mailing list for project created.

OK

* Solves a core application security need.

OK since selected for the OWASP SoC

'''What has been done by the authors'''

* documents:

server concept and architecture : to be completed, Alpha quality OK

* implementation:

draft of the welcome page of the OpenSign Server Web Interface.

code structure

'''Summary'''

* The criteria for alpha quality of the OpenSign Projects have been met before the 2008.07.15

* What has not been done:

Implementation of the helper tools in Java. Only C++ versions are available. To let the project authors focus on the system architecture and basic functionalities, it has been decided that the availability of Java tools was not a priority requirement for the OpenSign project.

|-
| style="width:25%; background:#7B8ABD" align="center"|

2. At what extent have the project deliveries & objectives been accomplished? Having in consideration [[OWASP Summer of Code 2008 Applications#Online code signing and integrity verification service for open source community (OpenSign Server)|'''the assumed ones''']], please quantify in terms of percentage.
| colspan="2" style="width:75%; background:#cccccc" align="left"|

Alpha Quality: 100 %.

Overall project: 50 %

Software development: 30 %

|-
|-
| style="width:25%; background:#7B8ABD" align="center"|
3. Please do use the right hand side column to provide advice and make work suggestions.
| colspan="2" style="width:75%; background:#cccccc" align="left"|
Document sent to the authors, 1. week of July [https://www.owasp.org/images/5/51/Review_opensign_pparrend_2008_07_04.doc]
|}

Project Information:template OpenSign Server Project - 50 Review - First Reviewer - C

2008-08-26T15:00:32Z

Pparrend:

File:Review opensign pparrend 2008 07 04.doc

2008-08-26T14:56:04Z

Pparrend: Review document that has been transfered to the project authors in the first week of July

Review document that has been transfered to the project authors in the first week of July

OWASP EU Summit 2008

2008-07-05T05:29:16Z

Pparrend: /* Summer of Code 08 Participants & Reviewers */

(WORK IN PROGRESS /UNDER DISCUSSION)
== UPDATES ==
*[[OWASP EU Summit 2008 - updates|'''OWASP EU Summit 2008 - updates''']]

== What: OWASP Summit, a conference about OWASP and for OWASP's community ==
=== When: 4 to 7 Nov 2008 (4 & 5: Meetings and Training, 6 & 7: Conference) ===
=== Where: Portugal ===
Faro or Lisbon
=== Organization===
Paulo Coimbra and Dinis Cruz
== Agenda ==
Theme: Present OWASP's projects, community and activities ..... '....Connecting the dots.... "

'''Day 1 & 2'''
*Training sessions (similar to what happens at the moment at the other OWASP conferences)
*OWASP Working Group sessions (1/2 day each) on:
** OWASP Governance, "What is OWASP's position on ...." & Action Plan for 2009
** ESAPI
** Browser Security
** OWASP Top 10 2009

'''Day 3 & 4 Agenda:'''
* Presentations from AoC, SpoC and SoC Participants
* Presentations from 'Release' Quality OWASP projects (not included in the list above) or Key OWASP projects (like ESAPI)
* Presentations about OWASP : How it works, Financial reports, OotM (OWASP on the Move), new project management guidelines, local chapter finances, OWASP governance
* Presentation from Chapter leaders on the activities developed on their project
* Discussion on next steps for OWASP and focus of next OWASP financial investment plans

Other ideas:

* vote on 6th OWASP board member (Candidates to Apply)

== other details==

'''Projected Attendees:450 '''
* 200 with some (or all) expenses covered by OWASP
** 33 SoC participants
** 70 SoC reviewers
** 10 SoC Collaborators
** 15 AoC & SpoC participants
** 15 Chapter Leaders
** 8 OWASP Board & Employees
** 49 OWASP non-individual members (2x per 9k Corporate? 1x for the others?)

=== Financial details ===
'''Expenses'''
* Accommodation & meals: 80,000 USD = 400 USD per person (200x) for 3 nights accommodation and 5 meals (3 dinners and 2 lunches)
* Flights & Trains : 70,000 USD

'''Revenue sources'''
* Tickets (for the 250 non 'OWASP invited' attendees)
* Training Sessions
* Conference sponsors

== Participants ==
=== OWASP Board members & employees ===
* Jeff Williams
* Dave Wichers
* Dinis Cruz
* Tom Brennan
* Sebastien Deleersnyder
* Paulo Coimbra
* Kate Hartmann (to be confirmed)
* Alison McNamee (to be confirmed)
* Larry Casey (to be confirmed)

=== Summer of Code 08 Participants & Reviewers ===
* (please add your name in the following format)
* OWASP Classic ASP Security Project
**Reviewer Esteban Ribicic Argentina -living in Croatia/Wien-
**Project Lead - Juan Carlos Calderon - Mexico
* OWASP Internationalization Guidelines
**Reviewer Esteban Ribicic Argentina -living in Croatia/Wien-
**Project Lead - Juan Carlos Calderon - Mexico
* OWASP Spanish Project Reviewer Esteban Ribicic
**Reviewer Esteban Ribicic Argentina -living in Croatia/Wien-
**Project Lead - Juan Carlos Calderon - Mexico
* OWASP Ruby on Rails Security Project Leader Heiko Webers from Germany
* OWASP Code Review Guide Lead - Eoin Keary - Ireland
* OWASP Enigform and mod_Openpgp - Arturo Alberto Busleiman (a.k.a Buanzo) - Argentina
* OWASP AppSensor - Michael Coates - United States
* OWASP ASDR - Leonardo Cavallari Militelli - Brazil
*OWASP Corporate Application security guide- Parvathy Iyer- USA
* OWASP Backend Security Project - Carlo Pelliccioni - Italy
* OWASP Source Code Review OWASP Projects - Marco M. Morana (2nd reviewer) - United States
* OWASP Access Control Rules Tester Project
**Project leader - Andrew Petukhov - Russia, Moscow
* OWASP Live CD 2008
** Project Leader - Matt Tesauro - Austin, USA
* OWASP OpenSign Server Project
** Reviewer Pierre Parrend - France

=== Spring of Code 07 Participants (Completed Projects) ===
* Refresh Attacks list - Przemyslaw Skowron - Poland

* (please add your name)
* {Project} {Name} {Origin Country}

=== Autumn of Code 06 Participants ===
* (please add your name)
* {Project} {Name} {Origin Country}

* WebScarab-NG, Rogan Dawes, South Africa
* OWASP Pantera, Simon Roses Femerling, Spain

=== Active Chapter Leaders ===
* (please add your name in the following format)
* {Chapter} {Role} {Name} {Origin Country}
* Helsinki chapter leader - Antti Laulajainen, Finland
* NY/NJ Metro Board Member - Steve Antoniewicz, USA
* Twin-Cities chapter leader - Kuai Hinojosa, MN, USA
* Hawaii chapter leader/founder - Jim Manico, Anahola, Island of Kauai, Hawaii, USA

=== Active Project Leaders (not currently participating on SoC 08)===
* (please add your name in the following format)
* {Project} {Role} {Name} {Origin Country}
.NET ESAPI - Project Leader - Alex Smolen - USA

=== Significant Past OWASP contributor (that is not already covered by one of the above categories) ===
* (please add your name in the following format)
* {Project/Chapter} {Role} {Name} {Origin Country}

=== Logistic and Support team ===
* Summit Graphic Design + Summit organization + on-site logistics support, Sarah Cruz, UK (London)

Mobile Java Security

2007-07-27T09:51:11Z

Pparrend: /* Presentations */

== Presentations ==

[https://www.owasp.org/images/6/60/Owasp_security4mobileJava.pdf Dependability for Java Mobile Code] - Pierre Parrend.

'''Abstract:'''

The recent increase of connected hand-held devices, through which the users access to the Internet and communicate with others, introduces a major programming model shift: applications are not only provided in a classical client-server fashion, but can also be loaded as mobile code on the end device. Consequently, new security threats arise: Malicious code can be hidden in the loaded code, and executed inside the device. A new approach to security is thus necessary: Dependability must be guaranteed, i.e. both usual security properties (Authentication, Integrity, Confidentiality) and robustness, so as to explicitly prevent DoS attacks.

The state of the art of security for Java Mobile Code (MIDP and OSGi) is presented, as well as our research work on dependability in the context of the OSGi Platform.

This presentation is the support for a talk that has been given for the [https://www.owasp.org/index.php/Switzerland OWASP Switzerland Local Chapter], the 24th of July, 2007.

[[Category:OWASP Java Project]]

Mobile Java Security

2007-07-26T16:16:03Z

Pparrend: /* Presentations */

== Presentations ==

[https://www.owasp.org/images/6/60/Owasp_security4mobileJava.pdf Dependability for Java Mobile Code] - Pierre Parrend (right-click and choose 'Save Link As' to download the presentation).

'''Abstract:'''

The recent increase of connected handheld devices, through which the users access to the Internet and communicate with others, introduces a major programming model shift: applications are not only provided in a classical client-server fashion, but can also be loaded as mobile code on the end device. Consequently, new security threats arise: Malicious code can be hidden in the loaded code, and executed inside the device. A new approach to security is thus necessary: Dependability must be guaranteed, i.e. both usual security properties (Authentication, Integrity, Confidentiality) and robustness, so as to explicitly prevent DoS attacks.

The state of the art of security for Java Mobile Code (MIDP and OSGi) is presented, as well as our research work on dependability in the context of the OSGi Platform.

This presentation is the support for a talk that has been given for the [https://www.owasp.org/index.php/Switzerland OWASP Switzerland Local Chapter], the 24th of July, 2007.

[[Category:OWASP Java Project]]

Mobile Java Security

2007-07-26T14:50:33Z

Pparrend:

== Presentations ==

[https://www.owasp.org/images/6/60/Owasp_security4mobileJava.pdf Dependability for Java Mobile Code] - Pierre Parrend

'''Abstract:'''

The recent increase of connected handheld devices, through which the users access to the Internet and communicate with others, introduces a major programming model shift: applications are not only provided in a classical client-server fashion, but can also be loaded as mobile code on the end device. Consequently, new security threats arise: Malicious code can be hidden in the loaded code, and executed inside the device. A new approach to security is thus necessary: Dependability must be guaranteed, i.e. both usual security properties (Authentication, Integrity, Confidentiality) and robustness, so as to explicitly prevent DoS attacks.

The state of the art of security for Java Mobile Code (MIDP and OSGi) is presented, as well as our research work on dependability in the context of the OSGi Platform.

This presentation is the support for a talk that has been given for the OWASP Group Swiss, the 24th of July, 2007.

[[Category:OWASP Java Project]]

Mobile Java Security

2007-07-26T14:49:06Z

Pparrend:

Bytecode obfuscation

2007-07-09T13:51:06Z

Pparrend:

==Author==
Pierre Parrend

== Principles ==

Java is a language where the source code is quite intuitive to read. And in many cases, the compiled bytecode can also be reversed (or decompiled) into source code. This presents problems for projects that require confidentiality of the source code. This article provides an introduction to protecting bytecode through obfuscation.

=== How to recover Source Code from Bytecode? ===

There are a number of freely available Java decompilers that all provide similar functionality, including:

* Recover source code from Java bytecode,
* Retrieve names of local Variables and parameters,
* Retrieve comments and JavaDoc

Popular decompilers include:
* [http://www.kpdus.com/jad.html JAD (JAva Decompiler)] - a little dated now and does not support Java 5.0
* [http://jode.sourceforge.net Jode] - Written entirely in Java and provides a Swing GUI
* [http://jrevpro.sourceforge.net/ jReversePro] - 100% Java, also slightly dated

=== How to prevent Java code from being Reverse-engineered ? ===

Several actions can be taken for preventing reverse-engineering :

* Code Obfuscation. This is done mainly through variable renaming; see next paragraph for more precisions,
* Suppression of End Of Line Characters. This makes the code difficult to parse,
* Use of anonymous classes for handling events. This seems not to be handled by many Decompiler; however, JAD copes pretty well with this.
* Class file encryption. This implies some overhead for uncyphering at runtime. Several tools are available:: [http://www.cinnabarsystems.com/canner.html Canner], by Cinnabar Systems, or [http://www.jbitsoftware.com/JBit/do/displayPage?targetPageId=products.jlockinfo JLock by JSoft]. They are available for evaluation, and the first is proposed currently for Windows Platforms only.
* Replacing the method names with certain characters e.g '/' or '.' in the class header causes the popular decompilation tools such as JAD to dump the source code which is incomprehensible (you cannot determine the control flow from the source).
Note: Beware of 100% Java solutions using encryption to protect class files as these are more than likely snake oil. Since the JVM has to read unencrypted class files at some point, even if the class files are encrypted on the disk, they will have to be decrypted before being passed to the JVM. An attacker could modify the local JVM to simply write the class files to disk in their unencrypted form at this point. (See: [http://www.javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html?page=2 Javaworld article]). 
Conjecture: It's is very easy to circumvent these methods to reveal bytecode using a Java profiler.

=== What obfuscation tools are available ? ===

A lot of tools exist for Java code Obfuscation. You can find extensive lists under following URLs, or simply type 'obfuscator' in your favorite search engine :

* http://directory.google.com/Top/Computers/Programming/Languages/Java/Development_Tools/Obfuscators/
* http://proguard.sourceforge.net/alternatives.html

Among those projects, some are open source project, and therefore more suitable for research - but also for enterprises who wish to control the programs they use (without any warranty):

* [http://proguard.sourceforge.net/ Proguard] is a shrinker (make code more compact), and optimizer and obfuscator.
* [http://jode.sourceforge.net/ Jode] is a decompiler, an optimizer and an obfuscator. It contains facilities for cleaning logging statements,,
* [http://jarg.sourceforge.net/ Jarg],
* [http://sourceforge.net/projects/javaguard/ Javaguard], which is a simple obfuscator, without many documentation,
* [http://www.geocities.com/CapeCanaveral/Hall/2334/Programs/cafebabe.html CafeBabe], which allows precise view of Bytecode files and single file obfuscation; a good tool for teaching ByteCode Structure, more than a production tool.

== Using Proguard ==

The following section provides a short tutorial for using [http://proguard.sourceforge.net/ Proguard].

First, download the code under [http://sourceforge.net/project/showfiles.php?group_id=54750 following url ] and unzip it.

For this tutorial, we use the [http://www.rzo.free.fr/applis/fr.inria.ares.sfelixutils-0.1.jar fr.inria.ares.sfelixutils-0.1.jar package].

Go to the main directory of Proguard. For lauching it, you can use following script with given parameters :

java -jar lib/proguard.jar @config-genericFrame.pro

config-genericFrame.pro is the option file
(do not forget to adapt the libraryjars parameter to your own system) :

-obfuscationdictionary ./examples/dictionaries/compact.txt
-libraryjars /usr/java/j2sdk1.4.2_10/jre/lib/rt.jar
-injars fr.inria.ares.sfelixutils-0.1.jar
-outjar fr.inria.ares.sfelixutils-0.1-obs.jar
-dontshrink
-dontoptimize
-keep public class proguard.ProGuard {
public static void main(java.lang.String[]);
}

Remark that the 'keep' option is mandatory, we use this default class for not keep anything out.

The example dictionnary (here compact.txt) is given with the code.

The output is stored in the package 'genericFrameOut.jar'.

You can observe the modifications implied by obfuscation with following commands :

jar xvf genericFrameOut.jar
cd genericFrame/pub/gui/
jad c.class
more c.jad more c.jad

Remark than Strings are kept unmodified. If you want you code to be hard to read, do not forget to remove any debugging and logging comments. Jode has some facilities for making this easier.

== Using CafeBabe ==

CafeBabe is a convenient tool for teaching structure of ByteCode files. You can [http://www.geocities.com/CapeCanaveral/Hall/2334/programs.html download it at this URL].

Unzip it and execute following command :
java -classpath CafeBabe.jar org.javalobby.apps.cafebabe.CafeBabe

Have a look at some class from the original genericFrame.jar package.

Then obfuscate it, and compare both - original and modified class :

* with the CafeBabe viewer,
* after decompiling it with JAD.

What conclusion can you draw of it ?

== Using Jode ==

Jode is to be found [http://jode.sourceforge.net/ here].

== Links ==

* [http://directory.google.com/Top/Computers/Programming/Languages/Java/Development_Tools/Obfuscators/ Obfuscator list, by Google]
* [http://proguard.sourceforge.net/alternatives.html alternatives proposed by proguard]
* [http://www.geocities.com/CapeCanaveral/Hall/2334/Programs/cafebabe.html CafeBabe]
* [http://www.cinnabarsystems.com/canner.html Canner]
* [http://www.kpdus.com/jad.html JAD (JAva Decompiler)]
* [http://jarg.sourceforge.net/ Jarg]
* [http://sourceforge.net/projects/javaguard/ Javaguard]
* [http://www.jbitsoftware.com/JBit/do/displayPage?targetPageId=products.jlockinfo JLock by JSoft]
* [http://jode.sourceforge.net/ Jode]
* [http://proguard.sourceforge.net/ Proguard]

[[Category:OWASP Java Project]]
[[Category:Countermeasure]]
[[Category:How To]]

OWASP Java Table of Contents

2007-03-07T21:33:20Z

Pparrend: /* Protecting Binaries */

Key:
* xx%: Progress status of the paragraph
* Review: The paragraph needs a review
* TD: Paragraph to be assigned

==[[J2EE Security for Architects]]==
Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.

Any other security concerns that should be addressed during the design phase should also be mentioned here.
===Design considerations===
* Architectural considerations (0%, TD)
** EJB Middle tier (0%, TD)
** Web Services Middle tier (0%, TD)
** Spring Middle tier (0%, TD)

==[[J2EE Security for Developers]]==
=== Noteworthy Frameworks ===
Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level, for example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.

(0%, Seeking Volunteers)
* Struts
* Turbine
* JFS (MyFaces)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring

===[[Java Security Basics]]===
Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.
* Class Loading (0%, Shyaam Sundar, Review)
* Bytecode verifier (0%, Shyaam Sundar, Review)
* The Security Manager and security.policy file (0%, Shyaam Sundar, Review)

===Input Validation Overview ===
Input validation is perhaps the most important category of application security. Any data entering a software system must be verified to contain safe data that is not mounting a SQL Injection, XSS, CSRF or other form of attack. This is done primarily through the use of regular expressions. It's crucial not to hard-code input validation routines. Regular expressions should contained within a configuration file that can easily updated by an InfoSec professional and not require a programmers intervention or deployment of new application code. Application security needs change over time as new attack vectors are discovered. Application administers need to be able to react to these changes as quickly as possible.

===Input Validation ===
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...) (0%, TD)
* [[How to add validation logic to HttpServletRequest]] (100%, Jeff Williams, Review)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Review)

==== [[Preventing SQL Injection in Java]] ====
* Overview
* Prevention (60%, Stephen de Vries, Review)
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis (60%, Rohyt Belani, Review)
** Spring JDBC
** EJB 3.0
** JDO

==== [[Preventing LDAP Injection in Java]] ====
* Overview (100%, Stephen de Vries, Review)
* Prevention (100%, Stephen de Vries, Review)

==== [[XPATH Injection]] ====
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.
* Overview (0%, TD)
* Prevention (0%, TD)

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting (0%, TD)
* Command injection - Runtime.getRuntime().exec() (0%, TD)

=== Authentication===
* Storing credentials - (0%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Using JCaptcha]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Reviewed by Pierre Parrend, Dave to act on comments)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* [[Password length & complexity]] - (0%, Adrian San Juan, Review)

===Session Management ===
The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples.
* Logout (0%, TD)
* Session Timeout (0%, TD)
* Absolute Timeout (0%, TD)
* [[Session Fixation in Java]] (100%, Rohyt Belani, Review)
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* Declarative v/s Programmatic (0%, TD)
* EJB Authorization (0%, TD)
* Acegi (0%, TD)
* JACC (0%, TD)
* Check horizontal privilege (0%, TD)

=== Encryption===
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions JCE] (80%, Joe Prasanna Kumar - To be reviewed)
* Storing db secrets (0%, TD)
* Encrypting JDBC connections (0%, TD)
* [http://www.owasp.org/index.php/Using_the_Java_Secure_Socket_Extensions JSSE] (80%, Joe Prasanna Kumar - To be reviewed)
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions Random number generation] (80%, Joe Prasanna Kumar - To be reviewed)

=== Error Handling & Logging===
* Logging - why log? what to log? log4j, etc. (0%, TD)
* Exception handling techniques (0%, TD)
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks (50%, TD)
** Servlet spec - web.xml [[Securing tomcat]] (100%, Darren Edmonds, Review)
** JSP errorPage (0%, TD)
* Web application forensics (0%, TD)

=== Web Services Security ===
* SAML (0%, TD)
* (X)WS-Security (0%, TD)
* SunJWSDP (0%, TD)
* XML Signature (JSR 105) (0%, TD)
* XML Encryption (JSR 106) (0%, TD)

=== Code Analysis Tools ===
The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.
* Introduction (0%, TD)
* [[:Category:OWASP LAPSE Project]] (100%, Review)
* FindBugs (0%, TD)
** Creating custom rules
* PMD (0%, TD)
** Creating custom rules
* JLint (0%, TD)
* Jmetrics (0%, TD)

== [[J2EE Security For Deployers]] ==
Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.
=== Securing Popular J2EE Servers ===
* [[Securing tomcat|Securing Tomcat]] - (100%, Darren Edmonds, Review)
* Securing JBoss (0%, TD)
* Securing WebLogic (0%, TD)
* Securing WebSphere (0%, TD)
* Others...

=== Defining a Java Security Policy ===
Practical information on creating a Java security policies for J2EE servers.
* PolicyTool (80%, Jeff Williams, Needs a new owner, Review)
* jChains (www.jchains.org) - (0%, TD)

=== Protecting Binaries ===
* Bytecode manipulation tools and techniques (0%, TD)
* [[Bytecode obfuscation]] (100%, Pierre Parrend, Review)
* Convert bytecode to native machine code (0%, TD)
* [[Protecting code archives with digital signatures]] (100%, Pierre Parrend, Review)
* [[Signing jar files with jarsigner]] (100%, Pierre Parrend, Review)

==[[J2EE Security for Security Analysts and Testers]]==
* Using Eclipse to verify Java applications (0%, TD)
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - (0%, TD)
* Decompiling Java bytecode (0%, TD)

== [[Java Security Resources]] (ongoing)==

[[Category:OWASP Java Project]]

File:Jarsigner-test.zip

2007-03-07T21:03:32Z

Pparrend: Example files for the Tutorial 'Editing Signing jar files with jarsigner'

Example files for the Tutorial 'Editing Signing jar files with jarsigner'

File:Bindex-manifestMainAttrsModified-1.0.jar

2007-02-08T20:59:22Z

Pparrend:

File:Fridgebundle-1.1.unknownsigner.jar

2007-02-08T20:58:57Z

Pparrend:

File:Fridgebundle-1.1.jar

2007-02-08T20:58:32Z

Pparrend:

File:Fridgebundle-1.1.signed.jar

2007-02-08T20:58:06Z

Pparrend:

OWASP Java Table of Contents

2007-02-08T17:51:40Z

Pparrend: /* Protecting Binaries */

Key:
* xx%: Progress status of the paragraph
* Review: The paragraph needs a review
* TD: Paragraph to be assigned

==[[J2EE Security for Architects]]==
Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.

Any other security concerns that should be addressed during the design phase should also be mentioned here.
===Design considerations===
* Architectural considerations (0%, TD)
** EJB Middle tier (0%, TD)
** Web Services Middle tier (0%, TD)
** Spring Middle tier (0%, TD)

==[[J2EE Security for Developers]]==
=== Noteworthy Frameworks ===
Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level, for example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.

(50% ?, Claire McDonough, Ranjita Shankar Iyer, Rohyt Belani to update, Review)
* Struts
* Turbine
* JFS (MyFaces)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring

===[[Java Security Basics]]===
Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.
* Class Loading (0%, Shyaam Sundar, Review)
* Bytecode verifier (0%, Shyaam Sundar, Review)
* The Security Manager and security.policy file (0%, Shyaam Sundar, Review)

===Input Validation Overview ===
Input validation is perhaps the most important category of application security. Any data entering a software system must be verified to contain safe data that is not mounting a SQL Injection, XSS, CSRF or other form of attack. This is done primarily through the use of regular expressions. It's crucial not to hard-code input validation routines. Regular expressions should contained within a configuration file that can easily updated by an InfoSec professional and not require a programmers intervention or deployment of new application code. Application security needs change over time as new attack vectors are discovered. Application administers need to be able to react to these changes as quickly as possible.

===Input Validation ===
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...) (0%, TD)
* [[How to add validation logic to HttpServletRequest]] (100%, Jeff Williams, Review)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Review)

==== [[Preventing SQL Injection in Java]] ====
* Overview
* Prevention (60%, Stephen de Vries, Review)
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis
** Spring JDBC
** EJB 3.0
** JDO

==== [[Preventing LDAP Injection in Java]] ====
* Overview (100%, Stephen de Vries, Review)
* Prevention (100%, Stephen de Vries, Review)

==== [[XPATH Injection]] ====
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.
* Overview (0%, TD)
* Prevention (0%, TD)

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting (0%, TD)
* Command injection - Runtime.getRuntime().exec() (0%, TD)

=== Authentication===
* Storing credentials - (0%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Using JCaptcha]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Reviewed by Pierre Parrend, Dave to act on comments)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* [[Password length & complexity]] - (0%, Adrian San Juan, Review)

===Session Management ===
The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples.
* Logout (0%, TD)
* Session Timeout (0%, TD)
* Absolute Timeout (0%, TD)
* Session Fixation (0%, TD)
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* Declarative v/s Programmatic (0%, TD)
* EJB Authorization (0%, TD)
* Acegi (0%, TD)
* JACC (0%, TD)
* Check horizontal privilege (0%, TD)

=== Encryption===
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions JCE] (80%, Joe Prasanna Kumar - To be reviewed)
* Storing db secrets (0%, TD)
* Encrypting JDBC connections (0%, TD)
* [http://www.owasp.org/index.php/Using_the_Java_Secure_Socket_Extensions JSSE] (80%, Joe Prasanna Kumar - To be reviewed)
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions Random number generation] (80%, Joe Prasanna Kumar - To be reviewed)

=== Error Handling & Logging===
* Logging - why log? what to log? log4j, etc. (0%, TD)
* Exception handling techniques (0%, TD)
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks (50%, TD)
** Servlet spec - web.xml [[Securing tomcat]] (100%, Darren Edmonds, Review)
** JSP errorPage (0%, TD)
* Web application forensics (0%, TD)

=== Web Services Security ===
* SAML (0%, TD)
* (X)WS-Security (0%, TD)
* SunJWSDP (0%, TD)
* XML Signature (JSR 105) (0%, TD)
* XML Encryption (JSR 106) (0%, TD)

=== Code Analysis Tools ===
The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.
* Introduction (0%, TD)
* [[:Category:OWASP LAPSE Project]] (100%, Review)
* FindBugs (0%, TD)
** Creating custom rules
* PMD (0%, TD)
** Creating custom rules
* JLint (0%, TD)
* Jmetrics (0%, TD)

== [[J2EE Security For Deployers]] ==
Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.
=== Securing Popular J2EE Servers ===
* [[Securing tomcat|Securing Tomcat]] - (100%, Darren Edmonds, Review)
* Securing JBoss (0%, TD)
* Securing WebLogic (0%, TD)
* Securing WebSphere (0%, TD)
* Others...

=== Defining a Java Security Policy ===
Practical information on creating a Java security policies for J2EE servers.
* PolicyTool (80%, Jeff Williams, Needs a new owner, Review)
* jChains (www.jchains.org) - (0%, TD)

=== Protecting Binaries ===
* Bytecode manipulation tools and techniques (0%, TD)
* [[Bytecode obfuscation]] (100%, Pierre Parrend, Review)
* Convert bytecode to native machine code (0%, TD)
* [[Protecting code archives with digital signatures]] (100%, Pierre Parrend, Review)
* [[Signing jar files with jarsigner]] (20%, Pierre Parrend)

==[[J2EE Security for Security Analysts and Testers]]==
* Using Eclipse to verify Java applications (0%, TD)
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - (0%, TD)
* Decompiling Java bytecode (0%, TD)

== [[Java Security Resources]] (ongoing)==

[[Category:OWASP Java Project]]

OWASP Java Table of Contents

2007-02-08T17:29:53Z

Pparrend: /* Protecting Binaries */

Key:
* xx%: Progress status of the paragraph
* Review: The paragraph needs a review
* TD: Paragraph to be assigned

==[[J2EE Security for Architects]]==
Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.

Any other security concerns that should be addressed during the design phase should also be mentioned here.
===Design considerations===
* Architectural considerations (0%, TD)
** EJB Middle tier (0%, TD)
** Web Services Middle tier (0%, TD)
** Spring Middle tier (0%, TD)

==[[J2EE Security for Developers]]==
=== Noteworthy Frameworks ===
Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level, for example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.

(50% ?, Claire McDonough, Ranjita Shankar Iyer, Rohyt Belani to update, Review)
* Struts
* Turbine
* JFS (MyFaces)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring

===[[Java Security Basics]]===
Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.
* Class Loading (0%, Shyaam Sundar, Review)
* Bytecode verifier (0%, Shyaam Sundar, Review)
* The Security Manager and security.policy file (0%, Shyaam Sundar, Review)

===Input Validation Overview ===
Input validation is perhaps the most important category of application security. Any data entering a software system must be verified to contain safe data that is not mounting a SQL Injection, XSS, CSRF or other form of attack. This is done primarily through the use of regular expressions. It's crucial not to hard-code input validation routines. Regular expressions should contained within a configuration file that can easily updated by an InfoSec professional and not require a programmers intervention or deployment of new application code. Application security needs change over time as new attack vectors are discovered. Application administers need to be able to react to these changes as quickly as possible.

===Input Validation ===
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...) (0%, TD)
* [[How to add validation logic to HttpServletRequest]] (100%, Jeff Williams, Review)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Review)

==== [[Preventing SQL Injection in Java]] ====
* Overview
* Prevention (60%, Stephen de Vries, Review)
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis
** Spring JDBC
** EJB 3.0
** JDO

==== [[Preventing LDAP Injection in Java]] ====
* Overview (100%, Stephen de Vries, Review)
* Prevention (100%, Stephen de Vries, Review)

==== [[XPATH Injection]] ====
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.
* Overview (0%, TD)
* Prevention (0%, TD)

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting (0%, TD)
* Command injection - Runtime.getRuntime().exec() (0%, TD)

=== Authentication===
* Storing credentials - (0%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Using JCaptcha]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Reviewed by Pierre Parrend, Dave to act on comments)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* [[Password length & complexity]] - (0%, Adrian San Juan, Review)

===Session Management ===
The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples.
* Logout (0%, TD)
* Session Timeout (0%, TD)
* Absolute Timeout (0%, TD)
* Session Fixation (0%, TD)
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* Declarative v/s Programmatic (0%, TD)
* EJB Authorization (0%, TD)
* Acegi (0%, TD)
* JACC (0%, TD)
* Check horizontal privilege (0%, TD)

=== Encryption===
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions JCE] (80%, Joe Prasanna Kumar - To be reviewed)
* Storing db secrets (0%, TD)
* Encrypting JDBC connections (0%, TD)
* [http://www.owasp.org/index.php/Using_the_Java_Secure_Socket_Extensions JSSE] (80%, Joe Prasanna Kumar - To be reviewed)
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions Random number generation] (80%, Joe Prasanna Kumar - To be reviewed)

=== Error Handling & Logging===
* Logging - why log? what to log? log4j, etc. (0%, TD)
* Exception handling techniques (0%, TD)
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks (50%, TD)
** Servlet spec - web.xml [[Securing tomcat]] (100%, Darren Edmonds, Review)
** JSP errorPage (0%, TD)
* Web application forensics (0%, TD)

=== Web Services Security ===
* SAML (0%, TD)
* (X)WS-Security (0%, TD)
* SunJWSDP (0%, TD)
* XML Signature (JSR 105) (0%, TD)
* XML Encryption (JSR 106) (0%, TD)

=== Code Analysis Tools ===
The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.
* Introduction (0%, TD)
* [[:Category:OWASP LAPSE Project]] (100%, Review)
* FindBugs (0%, TD)
** Creating custom rules
* PMD (0%, TD)
** Creating custom rules
* JLint (0%, TD)
* Jmetrics (0%, TD)

== [[J2EE Security For Deployers]] ==
Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.
=== Securing Popular J2EE Servers ===
* [[Securing tomcat|Securing Tomcat]] - (100%, Darren Edmonds, Review)
* Securing JBoss (0%, TD)
* Securing WebLogic (0%, TD)
* Securing WebSphere (0%, TD)
* Others...

=== Defining a Java Security Policy ===
Practical information on creating a Java security policies for J2EE servers.
* PolicyTool (80%, Jeff Williams, Needs a new owner, Review)
* jChains (www.jchains.org) - (0%, TD)

=== Protecting Binaries ===
* Bytecode manipulation tools and techniques (0%, TD)
* [[Bytecode obfuscation]] (100%, Pierre Parrend, Review)
* Convert bytecode to native machine code (0%, TD)
* [[Protecting code archives with digital signatures]] (100%, Pierre Parrend, Review)
* [[Signing jar files with jarsigner]] (0%, Pierre Parrend)

==[[J2EE Security for Security Analysts and Testers]]==
* Using Eclipse to verify Java applications (0%, TD)
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - (0%, TD)
* Decompiling Java bytecode (0%, TD)

== [[Java Security Resources]] (ongoing)==

[[Category:OWASP Java Project]]

OWASP Java Table of Contents

2006-11-21T10:26:59Z

Pparrend: /* Protecting Binaries */

Key:
* xx%: Progress status of the paragraph
* Review: The paragraph needs a review
* TD: Paragraph to be assigned

==[[J2EE Security for Architects]]==
Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.

Any other security concerns that should be addressed during the design phase should also be mentioned here.
===Design considerations===
* Architectural considerations (0%, TD)
** EJB Middle tier (0%, TD)
** Web Services Middle tier (0%, TD)
** Spring Middle tier (0%, TD)

==[[J2EE Security for Developers]]==
=== Noteworthy Frameworks ===
Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level, for example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.

(50% ?, Claire McDonough, Ranjita Shankar Iyer, Rohyt Belani to update, Review)
* Struts
* Turbine
* JFS (MyFaces)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring

===[[Java Security Basics]]===
Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.
* Class Loading (0%, Shyaam Sundar, Review)
* Bytecode verifier (0%, Shyaam Sundar, Review)
* The Security Manager and security.policy file (0%, Shyaam Sundar, Review)

===Input Validation===
* Overview (0%, TD)
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...) (0%, TD)
* [[How to add validation logic to HttpServletRequest]] (100%, Jeff Williams, Review)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Review)

==== [[Preventing SQL Injection in Java]] ====
* Overview
* Prevention (60%, Stephen de Vries, Review)
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis
** Spring JDBC
** EJB 3.0
** JDO

==== [[Preventing LDAP Injection in Java]] ====
* Overview (100%, Stephen de Vries, Review)
* Prevention (100%, Stephen de Vries, Review)

==== [[XPATH Injection]] ====
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.
* Overview (0%, TD)
* Prevention (0%, TD)

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting (0%, TD)
* Command injection - Runtime.getRuntime().exec() (0%, TD)

=== Authentication===
* Storing credentials - (0%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Using JCaptcha]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Reviewed by Pierre Parrend, Dave to act on comments)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* Password length & complexity - (0%, Adrian San Juan, Review)

===Session Management ===
The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples.
* Logout (0%, TD)
* Session Timeout (0%, TD)
* Absolute Timeout (0%, TD)
* Session Fixation (0%, TD)
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* Declarative v/s Programmatic (0%, TD)
* EJB Authorization (0%, TD)
* Acegi (0%, TD)
* JACC (0%, TD)
* Check horizontal privilege (0%, TD)

=== Encryption===
* JCE (0%, TD)
* Storing db secrets (0%, TD)
* Encrypting JDBC connections (0%, TD)
* JSSE (0%, TD)
* Random number generation (0%, TD)

=== Error Handling & Logging===
* Logging - why log? what to log? log4j, etc. (0%, TD)
* Exception handling techniques (0%, TD)
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks (50%, TD)
** Servlet spec - web.xml [[Securing tomcat]] (100%, Darren Edmonds, Review)
** JSP errorPage (0%, TD)
* Web application forensics (0%, TD)

=== Web Services Security ===
* SAML (0%, TD)
* (X)WS-Security (0%, TD)
* SunJWSDP (0%, TD)
* XML Signature (JSR 105) (0%, TD)
* XML Encryption (JSR 106) (0%, TD)

=== Code Analysis Tools ===
The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.
* Introduction (0%, TD)
* [[:Category:OWASP LAPSE Project]] (100%, Review)
* FindBugs (0%, TD)
** Creating custom rules
* PMD (0%, TD)
** Creating custom rules
* JLint (0%, TD)
* Jmetrics (0%, TD)

== [[J2EE Security For Deployers]] ==
Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.
=== Securing Popular J2EE Servers ===
* [[Securing tomcat|Securing Tomcat]] - (100%, Darren Edmonds, Review)
* Securing JBoss (0%, TD)
* Securing WebLogic (0%, TD)
* Securing WebSphere (0%, TD)
* Others...

=== Defining a Java Security Policy ===
Practical information on creating a Java security policies for J2EE servers.
* PolicyTool (80%, Jeff Williams, Needs a new owner, Review)
* jChains (www.jchains.org) - (0%, TD)

=== Protecting Binaries ===
* Bytecode manipulation tools and techniques (0%, TD)
* [[Bytecode obfuscation]] (100%, Pierre Parrend, Review)
* Convert bytecode to native machine code (0%, TD)
* [[Protecting code archives with digital signatures]] (100%, Pierre Parrend, Review)
* Signing jar files with jarsigner (0%, Pierre Parrend)

==[[J2EE Security for Security Analysts and Testers]]==
* Using Eclipse to verify Java applications (0%, TD)
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - (0%, TD)
* Decompiling Java bytecode (0%, TD)

== [[Java Security Resources]] (ongoing)==

[[Category:OWASP Java Project]]

OWASP Java Table of Contents

2006-11-21T10:26:34Z

Pparrend: /* Protecting Binaries */

Key:
* xx%: Progress status of the paragraph
* Review: The paragraph needs a review
* TD: Paragraph to be assigned

==[[J2EE Security for Architects]]==
Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.

Any other security concerns that should be addressed during the design phase should also be mentioned here.
===Design considerations===
* Architectural considerations (0%, TD)
** EJB Middle tier (0%, TD)
** Web Services Middle tier (0%, TD)
** Spring Middle tier (0%, TD)

==[[J2EE Security for Developers]]==
=== Noteworthy Frameworks ===
Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level, for example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.

(50% ?, Claire McDonough, Ranjita Shankar Iyer, Rohyt Belani to update, Review)
* Struts
* Turbine
* JFS (MyFaces)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring

===[[Java Security Basics]]===
Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.
* Class Loading (0%, Shyaam Sundar, Review)
* Bytecode verifier (0%, Shyaam Sundar, Review)
* The Security Manager and security.policy file (0%, Shyaam Sundar, Review)

===Input Validation===
* Overview (0%, TD)
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...) (0%, TD)
* [[How to add validation logic to HttpServletRequest]] (100%, Jeff Williams, Review)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Review)

==== [[Preventing SQL Injection in Java]] ====
* Overview
* Prevention (60%, Stephen de Vries, Review)
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis
** Spring JDBC
** EJB 3.0
** JDO

==== [[Preventing LDAP Injection in Java]] ====
* Overview (100%, Stephen de Vries, Review)
* Prevention (100%, Stephen de Vries, Review)

==== [[XPATH Injection]] ====
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.
* Overview (0%, TD)
* Prevention (0%, TD)

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting (0%, TD)
* Command injection - Runtime.getRuntime().exec() (0%, TD)

=== Authentication===
* Storing credentials - (0%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Using JCaptcha]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Reviewed by Pierre Parrend, Dave to act on comments)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* Password length & complexity - (0%, Adrian San Juan, Review)

===Session Management ===
The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples.
* Logout (0%, TD)
* Session Timeout (0%, TD)
* Absolute Timeout (0%, TD)
* Session Fixation (0%, TD)
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* Declarative v/s Programmatic (0%, TD)
* EJB Authorization (0%, TD)
* Acegi (0%, TD)
* JACC (0%, TD)
* Check horizontal privilege (0%, TD)

=== Encryption===
* JCE (0%, TD)
* Storing db secrets (0%, TD)
* Encrypting JDBC connections (0%, TD)
* JSSE (0%, TD)
* Random number generation (0%, TD)

=== Error Handling & Logging===
* Logging - why log? what to log? log4j, etc. (0%, TD)
* Exception handling techniques (0%, TD)
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks (50%, TD)
** Servlet spec - web.xml [[Securing tomcat]] (100%, Darren Edmonds, Review)
** JSP errorPage (0%, TD)
* Web application forensics (0%, TD)

=== Web Services Security ===
* SAML (0%, TD)
* (X)WS-Security (0%, TD)
* SunJWSDP (0%, TD)
* XML Signature (JSR 105) (0%, TD)
* XML Encryption (JSR 106) (0%, TD)

=== Code Analysis Tools ===
The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.
* Introduction (0%, TD)
* [[:Category:OWASP LAPSE Project]] (100%, Review)
* FindBugs (0%, TD)
** Creating custom rules
* PMD (0%, TD)
** Creating custom rules
* JLint (0%, TD)
* Jmetrics (0%, TD)

== [[J2EE Security For Deployers]] ==
Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.
=== Securing Popular J2EE Servers ===
* [[Securing tomcat|Securing Tomcat]] - (100%, Darren Edmonds, Review)
* Securing JBoss (0%, TD)
* Securing WebLogic (0%, TD)
* Securing WebSphere (0%, TD)
* Others...

=== Defining a Java Security Policy ===
Practical information on creating a Java security policies for J2EE servers.
* PolicyTool (80%, Jeff Williams, Needs a new owner, Review)
* jChains (www.jchains.org) - (0%, TD)

=== Protecting Binaries ===
* Bytecode manipulation tools and techniques (0%, TD)
* [[Bytecode obfuscation]] (100%, Pierre Parrend, Review)
* Convert bytecode to native machine code (0%, TD)
* [[Protecting code archives with digital signatures]] (100%, Pierre Parrend)
* Signing jar files with jarsigner (0%, Pierre Parrend)

==[[J2EE Security for Security Analysts and Testers]]==
* Using Eclipse to verify Java applications (0%, TD)
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - (0%, TD)
* Decompiling Java bytecode (0%, TD)

== [[Java Security Resources]] (ongoing)==

[[Category:OWASP Java Project]]

Talk:Protecting code archives with digital signatures

2006-11-21T10:25:46Z

Pparrend:

==Status==
Needs review

==Authors==
* Pierre Parrend

==Reviewers==
*

==General Discussion==
* 'An example with OSGi bundles' should be a subtitle, not a paragraph title.

File:Validation-algorithm lt.png

2006-11-21T10:16:07Z

Pparrend:

File:Signature-algorithm lt.png

2006-11-21T10:15:33Z

Pparrend:

File:Bundle-signed-example lt.png

2006-11-21T10:15:02Z

Pparrend:

File:Component-deployment-pbs lt.png

2006-11-21T10:13:01Z

Pparrend:

OWASP Java Table of Contents

2006-11-21T09:58:01Z

Pparrend: /* Protecting Binaries */

Key:
* xx%: Progress status of the paragraph
* Review: The paragraph needs a review
* TD: Paragraph to be assigned

==[[J2EE Security for Architects]]==
Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.

Any other security concerns that should be addressed during the design phase should also be mentioned here.
===Design considerations===
* Architectural considerations (0%, TD)
** EJB Middle tier (0%, TD)
** Web Services Middle tier (0%, TD)
** Spring Middle tier (0%, TD)

==[[J2EE Security for Developers]]==
=== Noteworthy Frameworks ===
Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level, for example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.

(50% ?, Claire McDonough, Ranjita Shankar Iyer, Rohyt Belani to update, Review)
* Struts
* Turbine
* JFS (MyFaces)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring

===[[Java Security Basics]]===
Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.
* Class Loading (0%, Shyaam Sundar, Review)
* Bytecode verifier (0%, Shyaam Sundar, Review)
* The Security Manager and security.policy file (0%, Shyaam Sundar, Review)

===Input Validation===
* Overview (0%, TD)
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...) (0%, TD)
* [[How to add validation logic to HttpServletRequest]] (100%, Jeff Williams, Review)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Review)

==== [[Preventing SQL Injection in Java]] ====
* Overview
* Prevention (60%, Stephen de Vries, Review)
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis
** Spring JDBC
** EJB 3.0
** JDO

==== [[Preventing LDAP Injection in Java]] ====
* Overview (100%, Stephen de Vries, Review)
* Prevention (100%, Stephen de Vries, Review)

==== [[XPATH Injection]] ====
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.
* Overview (0%, TD)
* Prevention (0%, TD)

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting (0%, TD)
* Command injection - Runtime.getRuntime().exec() (0%, TD)

=== Authentication===
* Storing credentials - (0%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Using JCaptcha]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Reviewed by Pierre Parrend, Dave to act on comments)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* Password length & complexity - (0%, Adrian San Juan, Review)

===Session Management ===
The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples.
* Logout (0%, TD)
* Session Timeout (0%, TD)
* Absolute Timeout (0%, TD)
* Session Fixation (0%, TD)
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* Declarative v/s Programmatic (0%, TD)
* EJB Authorization (0%, TD)
* Acegi (0%, TD)
* JACC (0%, TD)
* Check horizontal privilege (0%, TD)

=== Encryption===
* JCE (0%, TD)
* Storing db secrets (0%, TD)
* Encrypting JDBC connections (0%, TD)
* JSSE (0%, TD)
* Random number generation (0%, TD)

=== Error Handling & Logging===
* Logging - why log? what to log? log4j, etc. (0%, TD)
* Exception handling techniques (0%, TD)
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks (50%, TD)
** Servlet spec - web.xml [[Securing tomcat]] (100%, Darren Edmonds, Review)
** JSP errorPage (0%, TD)
* Web application forensics (0%, TD)

=== Web Services Security ===
* SAML (0%, TD)
* (X)WS-Security (0%, TD)
* SunJWSDP (0%, TD)
* XML Signature (JSR 105) (0%, TD)
* XML Encryption (JSR 106) (0%, TD)

=== Code Analysis Tools ===
The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.
* Introduction (0%, TD)
* [[:Category:OWASP LAPSE Project]] (100%, Review)
* FindBugs (0%, TD)
** Creating custom rules
* PMD (0%, TD)
** Creating custom rules
* JLint (0%, TD)
* Jmetrics (0%, TD)

== [[J2EE Security For Deployers]] ==
Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.
=== Securing Popular J2EE Servers ===
* [[Securing tomcat|Securing Tomcat]] - (100%, Darren Edmonds, Review)
* Securing JBoss (0%, TD)
* Securing WebLogic (0%, TD)
* Securing WebSphere (0%, TD)
* Others...

=== Defining a Java Security Policy ===
Practical information on creating a Java security policies for J2EE servers.
* PolicyTool (80%, Jeff Williams, Needs a new owner, Review)
* jChains (www.jchains.org) - (0%, TD)

=== Protecting Binaries ===
* Bytecode manipulation tools and techniques (0%, TD)
* [[Bytecode obfuscation]] (100%, Pierre Parrend, Review)
* Convert bytecode to native machine code (0%, TD)
* [[Protecting code archives with digital signatures]] (0%, Pierre Parrend)
* Signing jar files with jarsigner (0%, Pierre Parrend)

==[[J2EE Security for Security Analysts and Testers]]==
* Using Eclipse to verify Java applications (0%, TD)
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - (0%, TD)
* Decompiling Java bytecode (0%, TD)

== [[Java Security Resources]] (ongoing)==

[[Category:OWASP Java Project]]

Talk:Trustworthy Java

2006-11-17T09:07:22Z

Pparrend: /* General Discussion */

==Status==
Under review

==Authors==
* Jeff Williams

==Reviewers==
* Pierre Parrend

==General Discussion==

* The article is built around the claim 'you should use MS Trustworthy in Java'. However, it does not clearly defines what the exact principles of Trustworthy Computing are.
* This makes the author of the article sounds more a MS fan that providing real solution. Perhaps technical solutions to the identified problem could prevent this shortcut.
* Otherwise, the article is agreable to read and well written.

Talk:Trustworthy Java

2006-11-17T09:06:18Z

Pparrend:

OWASP Java Table of Contents

2006-11-15T09:00:11Z

Pparrend: /* Protecting Binaries */

Key:
* xx%: Progress status of the paragraph
* Review: The paragraph needs a review
* TD: Paragraph to be assigned

==[[J2EE Security for Architects]]==
Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.

Any other security concerns that should be addressed during the design phase should also be mentioned here.
===Design considerations===
* Architectural considerations (0%, TD)
** EJB Middle tier (0%, TD)
** Web Services Middle tier (0%, TD)
** Spring Middle tier (0%, TD)

==[[J2EE Security for Developers]]==
=== Noteworthy Frameworks ===
Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level, for example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.

(50% ?, Claire McDonough, Ranjita Shankar Iyer, Rohyt Belani to update, Review)
* Struts
* Turbine
* JFS (MyFaces)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring

===[[Java Security Basics]]===
Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.
* Class Loading (0%, Shyaam Sundar, Review)
* Bytecode verifier (0%, Shyaam Sundar, Review)
* The Security Manager and security.policy file (0%, Shyaam Sundar, Review)

===Input Validation===
* Overview (0%, TD)
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...) (0%, TD)
* [[How to add validation logic to HttpServletRequest]] (100%, Jeff Williams, Review)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Review)

==== [[Preventing SQL Injection in Java]] ====
* Overview
* Prevention (60%, Stephen de Vries, Review)
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis
** Spring JDBC
** EJB 3.0
** JDO

==== [[Preventing LDAP Injection in Java]] ====
* Overview (100%, Stephen de Vries, Review)
* Prevention (100%, Stephen de Vries, Review)

==== [[XPATH Injection]] ====
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.
* Overview (0%, TD)
* Prevention (0%, TD)

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting (0%, TD)
* Command injection - Runtime.getRuntime().exec() (0%, TD)

=== Authentication===
* Storing credentials - (0%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Using JCaptcha]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Reviewed by Pierre Parrend, Dave to act on comments)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* Password length & complexity - (0%, Adrian San Juan, Review)

===Session Management ===
The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples.
* Logout (0%, TD)
* Session Timeout (0%, TD)
* Absolute Timeout (0%, TD)
* Session Fixation (0%, TD)
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* Declarative v/s Programmatic (0%, TD)
* EJB Authorization (0%, TD)
* Acegi (0%, TD)
* JACC (0%, TD)
* Check horizontal privilege (0%, TD)

=== Encryption===
* JCE (0%, TD)
* Storing db secrets (0%, TD)
* Encrypting JDBC connections (0%, TD)
* JSSE (0%, TD)
* Random number generation (0%, TD)

=== Error Handling & Logging===
* Logging - why log? what to log? log4j, etc. (0%, TD)
* Exception handling techniques (0%, TD)
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks (50%, TD)
** Servlet spec - web.xml [[Securing tomcat]] (100%, Darren Edmonds, Review)
** JSP errorPage (0%, TD)
* Web application forensics (0%, TD)

=== Web Services Security ===
* SAML (0%, TD)
* (X)WS-Security (0%, TD)
* SunJWSDP (0%, TD)
* XML Signature (JSR 105) (0%, TD)
* XML Encryption (JSR 106) (0%, TD)

=== Code Analysis Tools ===
The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.
* Introduction (0%, TD)
* [[:Category:OWASP LAPSE Project]] (100%, Review)
* FindBugs (0%, TD)
** Creating custom rules
* PMD (0%, TD)
** Creating custom rules
* JLint (0%, TD)
* Jmetrics (0%, TD)

== [[J2EE Security For Deployers]] ==
Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.
=== Securing Popular J2EE Servers ===
* [[Securing tomcat|Securing Tomcat]] - (100%, Darren Edmonds, Review)
* Securing JBoss (0%, TD)
* Securing WebLogic (0%, TD)
* Securing WebSphere (0%, TD)
* Others...

=== Defining a Java Security Policy ===
Practical information on creating a Java security policies for J2EE servers.
* PolicyTool (80%, Jeff Williams, Needs a new owner, Review)
* jChains (www.jchains.org) - (0%, TD)

=== Protecting Binaries ===
* Bytecode manipulation tools and techniques (0%, TD)
* [[Bytecode obfuscation]] (100%, Pierre Parrend, TD)
* Convert bytecode to native machine code (0%, TD)
* Signing jar files with jarsigner (0%, TD)

==[[J2EE Security for Security Analysts and Testers]]==
* Using Eclipse to verify Java applications (0%, TD)
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - (0%, TD)
* Decompiling Java bytecode (0%, TD)

== [[Java Security Resources]] (ongoing)==

[[Category:OWASP Java Project]]

Talk:Bytecode obfuscation

2006-11-15T08:58:36Z

Pparrend:

Relative to the categories of this article:

* the 'Countermeasure' category does not contain adequate sub-category. Should we add a 'Code Protection' one ?
* I put the article in the category 'Howto', because it is a pragmatic tutorial. However, it is not named 'Howto perform code obfuscation', and so looks strange in the list of howtos: https://www.owasp.org/index.php/Category:How_To.

Bytecode obfuscation

2006-11-15T08:53:23Z

Pparrend: /* Links */

== Principles ==

Java is a language which code is quite intuitive to read. But some also complain that compiled code is as easy to read as source code - or at least it is easy to recover. You will find here a couple of hints and tips about this matter of fact, and how to deal with it if you need to prevent people to exploit code they should not work with.

=== How to recover Source Code from Bytecode? ===

The main program for uncompiling code is [http://www.kpdus.com/jad.html JAD (JAva Decompiler)]. It provides following advantages :

* Recover code from Java ByteCode,
* Get clean code for your own programs,
* Remove Comments, Javadoc, Names of local Variables, Names of Parameters,
* Several Graphical interfaces, available on the web site.

=== How to prevent your Java code to be Reverse-engineered ? ===

Several actions can be taken for preventing reverse-engineering :

* Code Obfuscation. This is done mainly through variable renaming; see next paragraph for more precisions,
* Suppression of End Of Line Characters. This makes the code difficult to parse,
* Use of anonymous classes for handling events. This seems not to be handled by many Decompiler; however, JAD copes pretty well with this.
* File encoding. This implies some overhead for uncyphering at runtime. Several tools are available:: [http://www.cinnabarsystems.com/canner.html Canner], by Cinnabar Systems, or [http://www.jbitsoftware.com/JBit/do/displayPage?targetPageId=products.jlockinfo JLock by JSoft]. They are available for evaluation, and the first is proposed currently for Windows Platforms only.

=== What tools do exists for Obfuscation ? ===

A lot of tools exist for Java code Obfuscation. You can find extensive lists under following URLs, or simply type 'obfuscator' in your favorite search engine :

* http://directory.google.com/Top/Computers/Programming/Languages/Java/Development_Tools/Obfuscators/
* http://proguard.sourceforge.net/alternatives.html

Among those projects, some are open source project, and therefore more suitable for research - but also for enterprises who wish to control the programs they use (without any warranty):

* [http://proguard.sourceforge.net/ Proguard] is a shrinker (make code more compact), and optimizer and obfuscator.
* [http://jode.sourceforge.net/ Jode] is a decompiler, an optimizer and an obfuscator. It contains facilities for cleaning logging statements,,
* [http://jarg.sourceforge.net/ Jarg],
* [http://sourceforge.net/projects/javaguard/ Javaguard], which is a simple obfuscator, without many documentation,
* [http://www.geocities.com/CapeCanaveral/Hall/2334/Programs/cafebabe.html CafeBabe], which allows precise view of Bytecode files and single file obfuscation; a good tool for teaching ByteCode Structure, more than a production tool.

== Using Proguard ==

The following section provides a short tutorial for using [http://proguard.sourceforge.net/ Proguard].

First, download the code under [http://sourceforge.net/project/showfiles.php?group_id=54750 following url ] and unzip it.

For this tutorial, we use the [http://www.rzo.free.fr/applis/fr.inria.ares.sfelixutils-0.1.jar fr.inria.ares.sfelixutils-0.1.jar package].

Go to the main directory of Proguard. For lauching it, you can use following script with given parameters :

java -jar lib/proguard.jar @config-genericFrame.pro

config-genericFrame.pro is the option file
(do not forget to adapt the libraryjars parameter to your own system) :

-obfuscationdictionary ./examples/dictionaries/compact.txt
-libraryjars /usr/java/j2sdk1.4.2_10/jre/lib/rt.jar
-injars fr.inria.ares.sfelixutils-0.1.jar
-outjar fr.inria.ares.sfelixutils-0.1-obs.jar
-dontshrink
-dontoptimize
-keep public class proguard.ProGuard {
public static void main(java.lang.String[]);
}

Remark that the 'keep' option is mandatory, we use this default class for not keep anything out.

The example dictionnary (here compact.txt) is given with the code.

The output is stored in the package 'genericFrameOut.jar'.

You can observe the modifications implied by obfuscation with following commands :

jar xvf genericFrameOut.jar
cd genericFrame/pub/gui/
jad c.class
more c.jad more c.jad

Remark than Strings are kept unmodified. If you want you code to be hard to read, do not forget to remove any debugging and logging comments. Jode has some facilities for making this easier.

== Using CafeBabe ==

CafeBabe is a convenient tool for teaching structure of ByteCode files. You can [http://www.geocities.com/CapeCanaveral/Hall/2334/programs.html download it at this URL].

Unzip it and execute following command :
java -classpath CafeBabe.jar org.javalobby.apps.cafebabe.CafeBabe

Have a look at some class from the original genericFrame.jar package.

Then obfuscate it, and compare both - original and modified class :

* with the CafeBabe viewer,
* after decompiling it with JAD.

What conclusion can you draw of it ?

== Using Jode ==

Jode is to be found [http://jode.sourceforge.net/ here].

== Links ==

* [http://directory.google.com/Top/Computers/Programming/Languages/Java/Development_Tools/Obfuscators/ Obfuscator list, by Google]
* [http://proguard.sourceforge.net/alternatives.html alternatives proposed by proguard]
* [http://www.geocities.com/CapeCanaveral/Hall/2334/Programs/cafebabe.html CafeBabe]
* [http://www.cinnabarsystems.com/canner.html Canner]
* [http://www.kpdus.com/jad.html JAD (JAva Decompiler)]
* [http://jarg.sourceforge.net/ Jarg]
* [http://sourceforge.net/projects/javaguard/ Javaguard]
* [http://www.jbitsoftware.com/JBit/do/displayPage?targetPageId=products.jlockinfo JLock by JSoft]
* [http://jode.sourceforge.net/ Jode]
* [http://proguard.sourceforge.net/ Proguard]

[[Category:OWASP Java Project]]
[[Category:Countermeasure]]
[[Category:How To]]

OWASP Java Table of Contents

2006-11-15T08:46:23Z

Pparrend: /* Protecting Binaries */

Key:
* xx%: Progress status of the paragraph
* Review: The paragraph needs a review
* TD: Paragraph to be assigned

==[[J2EE Security for Architects]]==
Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.

Any other security concerns that should be addressed during the design phase should also be mentioned here.
===Design considerations===
* Architectural considerations (0%, TD)
** EJB Middle tier (0%, TD)
** Web Services Middle tier (0%, TD)
** Spring Middle tier (0%, TD)

==[[J2EE Security for Developers]]==
=== Noteworthy Frameworks ===
Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level, for example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.

(50% ?, Claire McDonough, Ranjita Shankar Iyer, Rohyt Belani to update, Review)
* Struts
* Turbine
* JFS (MyFaces)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring

===[[Java Security Basics]]===
Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.
* Class Loading (0%, Shyaam Sundar, Review)
* Bytecode verifier (0%, Shyaam Sundar, Review)
* The Security Manager and security.policy file (0%, Shyaam Sundar, Review)

===Input Validation===
* Overview (0%, TD)
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...) (0%, TD)
* [[How to add validation logic to HttpServletRequest]] (100%, Jeff Williams, Review)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Review)

==== [[Preventing SQL Injection in Java]] ====
* Overview
* Prevention (60%, Stephen de Vries, Review)
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis
** Spring JDBC
** EJB 3.0
** JDO

==== [[Preventing LDAP Injection in Java]] ====
* Overview (100%, Stephen de Vries, Review)
* Prevention (100%, Stephen de Vries, Review)

==== [[XPATH Injection]] ====
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.
* Overview (0%, TD)
* Prevention (0%, TD)

==== Miscellaneous Injection Attacks ====
* HTTP Response splitting (0%, TD)
* Command injection - Runtime.getRuntime().exec() (0%, TD)

=== Authentication===
* Storing credentials - (0%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Using JCaptcha]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Reviewed by Pierre Parrend, Dave to act on comments)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* Password length & complexity - (0%, Adrian San Juan, Review)

===Session Management ===
The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples.
* Logout (0%, TD)
* Session Timeout (0%, TD)
* Absolute Timeout (0%, TD)
* Session Fixation (0%, TD)
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* Declarative v/s Programmatic (0%, TD)
* EJB Authorization (0%, TD)
* Acegi (0%, TD)
* JACC (0%, TD)
* Check horizontal privilege (0%, TD)

=== Encryption===
* JCE (0%, TD)
* Storing db secrets (0%, TD)
* Encrypting JDBC connections (0%, TD)
* JSSE (0%, TD)
* Random number generation (0%, TD)

=== Error Handling & Logging===
* Logging - why log? what to log? log4j, etc. (0%, TD)
* Exception handling techniques (0%, TD)
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks (50%, TD)
** Servlet spec - web.xml [[Securing tomcat]] (100%, Darren Edmonds, Review)
** JSP errorPage (0%, TD)
* Web application forensics (0%, TD)

=== Web Services Security ===
* SAML (0%, TD)
* (X)WS-Security (0%, TD)
* SunJWSDP (0%, TD)
* XML Signature (JSR 105) (0%, TD)
* XML Encryption (JSR 106) (0%, TD)

=== Code Analysis Tools ===
The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.
* Introduction (0%, TD)
* [[:Category:OWASP LAPSE Project]] (100%, Review)
* FindBugs (0%, TD)
** Creating custom rules
* PMD (0%, TD)
** Creating custom rules
* JLint (0%, TD)
* Jmetrics (0%, TD)

== [[J2EE Security For Deployers]] ==
Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.
=== Securing Popular J2EE Servers ===
* [[Securing tomcat|Securing Tomcat]] - (100%, Darren Edmonds, Review)
* Securing JBoss (0%, TD)
* Securing WebLogic (0%, TD)
* Securing WebSphere (0%, TD)
* Others...

=== Defining a Java Security Policy ===
Practical information on creating a Java security policies for J2EE servers.
* PolicyTool (80%, Jeff Williams, Needs a new owner, Review)
* jChains (www.jchains.org) - (0%, TD)

=== Protecting Binaries ===
* Bytecode manipulation tools and techniques (0%, TD)
* [[Bytecode obfuscation]] (90%, Pierre Parrend, TD)
* Convert bytecode to native machine code (0%, TD)
* Signing jar files with jarsigner (0%, TD)

==[[J2EE Security for Security Analysts and Testers]]==
* Using Eclipse to verify Java applications (0%, TD)
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - (0%, TD)
* Decompiling Java bytecode (0%, TD)

== [[Java Security Resources]] (ongoing)==

[[Category:OWASP Java Project]]

Bytecode obfuscation

2006-11-15T08:44:59Z

Pparrend: /* Links */

Bytecode obfuscation

2006-11-15T08:40:39Z

Pparrend: /* Using Proguard */

Bytecode obfuscation

2006-11-15T08:34:40Z

Pparrend: /* Using Proguard */

== Principles ==

Java is a language which code is quite intuitive to read. But some also complain that compiled code is as easy to read as source code - or at least it is easy to recover. You will find here a couple of hints and tips about this matter of fact, and how to deal with it if you need to prevent people to exploit code they should not work with.

=== How to recover Source Code from Bytecode? ===

The main program for uncompiling code is [http://www.kpdus.com/jad.html JAD (JAva Decompiler)]. It provides following advantages :

* Recover code from Java ByteCode,
* Get clean code for your own programs,
* Remove Comments, Javadoc, Names of local Variables, Names of Parameters,
* Several Graphical interfaces, available on the web site.

=== How to prevent your Java code to be Reverse-engineered ? ===

Several actions can be taken for preventing reverse-engineering :

* Code Obfuscation. This is done mainly through variable renaming; see next paragraph for more precisions,
* Suppression of End Of Line Characters. This makes the code difficult to parse,
* Use of anonymous classes for handling events. This seems not to be handled by many Decompiler; however, JAD copes pretty well with this.
* File encoding. This implies some overhead for uncyphering at runtime. Several tools are available:: [http://www.cinnabarsystems.com/canner.html Canner], by Cinnabar Systems, or [http://www.jbitsoftware.com/JBit/do/displayPage?targetPageId=products.jlockinfo JLock by JSoft]. They are available for evaluation, and the first is proposed currently for Windows Platforms only.

=== What tools do exists for Obfuscation ? ===

A lot of tools exist for Java code Obfuscation. You can find extensive lists under following URLs, or simply type 'obfuscator' in your favorite search engine :

* http://directory.google.com/Top/Computers/Programming/Languages/Java/Development_Tools/Obfuscators/
* http://proguard.sourceforge.net/alternatives.html

Among those projects, some are open source project, and therefore more suitable for research - but also for enterprises who wish to control the programs they use (without any warranty):

* [http://proguard.sourceforge.net/ Proguard] is a shrinker (make code more compact), and optimizer and obfuscator.
* [http://jode.sourceforge.net/ Jode] is a decompiler, an optimizer and an obfuscator. It contains facilities for cleaning logging statements,,
* [http://jarg.sourceforge.net/ Jarg],
* [http://sourceforge.net/projects/javaguard/ Javaguard], which is a simple obfuscator, without many documentation,
* [http://www.geocities.com/CapeCanaveral/Hall/2334/Programs/cafebabe.html CafeBabe], which allows precise view of Bytecode files and single file obfuscation; a good tool for teaching ByteCode Structure, more than a production tool.

== Using Proguard ==

The following section provides a short tutorial for using [http://proguard.sourceforge.net/ Proguard].

First, download the code under [http://sourceforge.net/project/showfiles.php?group_id=54750 following url ] and unzip it.

For this tutorial, we use the [http://www.rzo.free.fr/applis/fr.inria.ares.sfelixutils-0.1.jar fr.inria.ares.sfelixutils-0.1.jar package].

Go tothe main directory of Proguard. For lauching it, you can use following script with given parameters :

java -jar lib/proguard.jar @config-genericFrame.pro

config-genericFrame.pro is the option file
(do not forget to adapt the libraryjars parameter to your own system) :

-obfuscationdictionary ./examples/dictionaries/compact.txt
-libraryjars /usr/java/j2sdk1.4.2_10/jre/lib/rt.jar
-injars fr.inria.ares.sfelixutils-0.1.jar
-outjar fr.inria.ares.sfelixutils-0.1-obs.jar
-dontshrink
-dontoptimize
-keep public class proguard.ProGuard {
public static void main(java.lang.String[]);
}

Remark that the 'keep' option is mandatory, we use this default class for not keep anything out.

The example dictionnary (here compact.txt) is given with the code.

The output is stored in the package 'genericFrameOut.jar'.

You can observe the modifications implied by obfuscation with following commands :

jar xvf genericFrameOut.jar
cd genericFrame/pub/gui/
jad c.class
more c.jad more c.jad

Remark than Strings are kept unmodified. If you want you code to be hard to read, do not forget to remove any debugging and logging comments. Jode has some facilities for making this easier.

== Using CafeBabe ==

CafeBabe is a convenient tool for teaching structure of ByteCode files. You can [http://www.geocities.com/CapeCanaveral/Hall/2334/programs.html download it at this URL].

Unzip it and execute following command :
java -classpath CafeBabe.jar org.javalobby.apps.cafebabe.CafeBabe

Have a look at some class from the original genericFrame.jar package.

Then obfuscate it, and compare both - original and modified class :

* with the CafeBabe viewer,
* after decompiling it with JAD.

What conclusion can you draw of it ?

== Using Jode ==

Jode is to be found [http://jode.sourceforge.net/ here].

== Links ==

Bytecode obfuscation

2006-11-15T08:22:11Z

Pparrend: /* Using Proguard */

== Principles ==

Java is a language which code is quite intuitive to read. But some also complain that compiled code is as easy to read as source code - or at least it is easy to recover. You will find here a couple of hints and tips about this matter of fact, and how to deal with it if you need to prevent people to exploit code they should not work with.

=== How to recover Source Code from Bytecode? ===

The main program for uncompiling code is [http://www.kpdus.com/jad.html JAD (JAva Decompiler)]. It provides following advantages :

* Recover code from Java ByteCode,
* Get clean code for your own programs,
* Remove Comments, Javadoc, Names of local Variables, Names of Parameters,
* Several Graphical interfaces, available on the web site.

=== How to prevent your Java code to be Reverse-engineered ? ===

Several actions can be taken for preventing reverse-engineering :

* Code Obfuscation. This is done mainly through variable renaming; see next paragraph for more precisions,
* Suppression of End Of Line Characters. This makes the code difficult to parse,
* Use of anonymous classes for handling events. This seems not to be handled by many Decompiler; however, JAD copes pretty well with this.
* File encoding. This implies some overhead for uncyphering at runtime. Several tools are available:: [http://www.cinnabarsystems.com/canner.html Canner], by Cinnabar Systems, or [http://www.jbitsoftware.com/JBit/do/displayPage?targetPageId=products.jlockinfo JLock by JSoft]. They are available for evaluation, and the first is proposed currently for Windows Platforms only.

=== What tools do exists for Obfuscation ? ===

A lot of tools exist for Java code Obfuscation. You can find extensive lists under following URLs, or simply type 'obfuscator' in your favorite search engine :

* http://directory.google.com/Top/Computers/Programming/Languages/Java/Development_Tools/Obfuscators/
* http://proguard.sourceforge.net/alternatives.html

Among those projects, some are open source project, and therefore more suitable for research - but also for enterprises who wish to control the programs they use (without any warranty):

* [http://proguard.sourceforge.net/ Proguard] is a shrinker (make code more compact), and optimizer and obfuscator.
* [http://jode.sourceforge.net/ Jode] is a decompiler, an optimizer and an obfuscator. It contains facilities for cleaning logging statements,,
* [http://jarg.sourceforge.net/ Jarg],
* [http://sourceforge.net/projects/javaguard/ Javaguard], which is a simple obfuscator, without many documentation,
* [http://www.geocities.com/CapeCanaveral/Hall/2334/Programs/cafebabe.html CafeBabe], which allows precise view of Bytecode files and single file obfuscation; a good tool for teaching ByteCode Structure, more than a production tool.

== Using Proguard ==

The following section provides a short tutorial for using [http://proguard.sourceforge.net/ Proguard].

First, download the code under [http://sourceforge.net/project/showfiles.php?group_id=54750 following url ] and unzip it.

For this tutorial, we use the [http://www.rzo.free.fr/applis/genericFrame.jar genericFrame.jar package], part of [http://www.rzo.free.fr/development.php a simple demo application ].

Go tothe main directory of Proguard. For lauching it, you can use following script with given parameters :

java -jar lib/proguard.jar @config-genericFrame.pro

config-genericFrame.pro is the option file
(do not forget to adapt the libraryjars parameter to your own system) :

-obfuscationdictionary ./examples/dictionaries/compact.txt
-libraryjars /usr/java/j2sdk1.4.2_10/jre/lib/rt.jar
-injars genericFrame.jar
-outjar genericFrameOut.jar
-dontshrink
-dontoptimize
-keep public class proguard.ProGuard {
public static void main(java.lang.String[]);
}

Remark that the 'keep' option is mandatory, we use this default class for not keep anything out.

The example dictionnary (here compact.txt) is given with the code.

The output is stored in the package 'genericFrameOut.jar'.

You can observe the modifications implied by obfuscation with following commands :

jar xvf genericFrameOut.jar
cd genericFrame/pub/gui/
jad c.class
more c.jad more c.jad

Remark than Strings are kept unmodified. If you want you code to be hard to read, do not forget to remove any debugging and logging comments. Jode has some facilities for making this easier.

== Using CafeBabe ==

CafeBabe is a convenient tool for teaching structure of ByteCode files. You can [http://www.geocities.com/CapeCanaveral/Hall/2334/programs.html download it at this URL].

Unzip it and execute following command :
java -classpath CafeBabe.jar org.javalobby.apps.cafebabe.CafeBabe

Have a look at some class from the original genericFrame.jar package.

Then obfuscate it, and compare both - original and modified class :

* with the CafeBabe viewer,
* after decompiling it with JAD.

What conclusion can you draw of it ?

== Using Jode ==

Jode is to be found [http://jode.sourceforge.net/ here].

== Links ==

Bytecode obfuscation

2006-11-15T08:14:23Z

Pparrend: /* How to prevent your Java code to be Reverse-engineered ? */

== Principles ==

Java is a language which code is quite intuitive to read. But some also complain that compiled code is as easy to read as source code - or at least it is easy to recover. You will find here a couple of hints and tips about this matter of fact, and how to deal with it if you need to prevent people to exploit code they should not work with.

=== How to recover Source Code from Bytecode? ===

The main program for uncompiling code is [http://www.kpdus.com/jad.html JAD (JAva Decompiler)]. It provides following advantages :

* Recover code from Java ByteCode,
* Get clean code for your own programs,
* Remove Comments, Javadoc, Names of local Variables, Names of Parameters,
* Several Graphical interfaces, available on the web site.

=== How to prevent your Java code to be Reverse-engineered ? ===

Several actions can be taken for preventing reverse-engineering :

* Code Obfuscation. This is done mainly through variable renaming; see next paragraph for more precisions,
* Suppression of End Of Line Characters. This makes the code difficult to parse,
* Use of anonymous classes for handling events. This seems not to be handled by many Decompiler; however, JAD copes pretty well with this.
* File encoding. This implies some overhead for uncyphering at runtime. Several tools are available:: [http://www.cinnabarsystems.com/canner.html Canner], by Cinnabar Systems, or [http://www.jbitsoftware.com/JBit/do/displayPage?targetPageId=products.jlockinfo JLock by JSoft]. They are available for evaluation, and the first is proposed currently for Windows Platforms only.

=== What tools do exists for Obfuscation ? ===

A lot of tools exist for Java code Obfuscation. You can find extensive lists under following URLs, or simply type 'obfuscator' in your favorite search engine :

* http://directory.google.com/Top/Computers/Programming/Languages/Java/Development_Tools/Obfuscators/
* http://proguard.sourceforge.net/alternatives.html

Among those projects, some are open source project, and therefore more suitable for research - but also for enterprises who wish to control the programs they use (without any warranty):

* [http://proguard.sourceforge.net/ Proguard] is a shrinker (make code more compact), and optimizer and obfuscator.
* [http://jode.sourceforge.net/ Jode] is a decompiler, an optimizer and an obfuscator. It contains facilities for cleaning logging statements,,
* [http://jarg.sourceforge.net/ Jarg],
* [http://sourceforge.net/projects/javaguard/ Javaguard], which is a simple obfuscator, without many documentation,
* [http://www.geocities.com/CapeCanaveral/Hall/2334/Programs/cafebabe.html CafeBabe], which allows precise view of Bytecode files and single file obfuscation; a good tool for teaching ByteCode Structure, more than a production tool.

== Using Proguard ==

The following section provides a short tutorial for using [http://proguard.sourceforge.net/ Proguard].

First, download the code under [http://sourceforge.net/project/showfiles.php?group_id=54750 following url ] and unzip it.

For this tutorial, we use the [http://www.rzo.free.fr/applis/genericFrame.jar genericFrame.jar package], part of [http://www.rzo.free.fr/development.php a simple demo application ].

Go tothe main directory of Proguard. For lauching it, you can use following script with given parameters :

java -jar lib/proguard.jar @config-genericFrame.pro

config-genericFrame.pro is the option file :

-obfuscationdictionary ./examples/dictionaries/compact.txt
-libraryjars /usr/java/j2sdk1.4.2_10/jre/lib/rt.jar
-injars genericFrame.jar
-outjar genericFrameOut.jar
-dontshrink
-dontoptimize
-keep public class proguard.ProGuard {
public static void main(java.lang.String[]);
}

Remark that the 'keep' option is mandatory, we use this default class for not keep anything out.

The example dictionnary (here compact.txt) is given with the code.

The output is stored in the package 'genericFrameOut.jar'.

You can observe the modifications implied by obfuscation with following commands :

jar xvf genericFrameOut.jar
cd genericFrame/pub/gui/
jad c.class
more c.jad more c.jad

Remark than Strings are kept unmodified. If you want you code to be hard to read, do not forget to remove any debugging and logging comments. Jode has some facilities for making this easier.

== Using CafeBabe ==

CafeBabe is a convenient tool for teaching structure of ByteCode files. You can [http://www.geocities.com/CapeCanaveral/Hall/2334/programs.html download it at this URL].

Unzip it and execute following command :
java -classpath CafeBabe.jar org.javalobby.apps.cafebabe.CafeBabe

Have a look at some class from the original genericFrame.jar package.

Then obfuscate it, and compare both - original and modified class :

* with the CafeBabe viewer,
* after decompiling it with JAD.

What conclusion can you draw of it ?

== Using Jode ==

Jode is to be found [http://jode.sourceforge.net/ here].

== Links ==

Bytecode obfuscation

2006-11-15T08:11:13Z

Pparrend: /* How to prevent your Java code to be Reverse-engineered ? */

== Principles ==

Java is a language which code is quite intuitive to read. But some also complain that compiled code is as easy to read as source code - or at least it is easy to recover. You will find here a couple of hints and tips about this matter of fact, and how to deal with it if you need to prevent people to exploit code they should not work with.

=== How to recover Source Code from Bytecode? ===

The main program for uncompiling code is [http://www.kpdus.com/jad.html JAD (JAva Decompiler)]. It provides following advantages :

* Recover code from Java ByteCode,
* Get clean code for your own programs,
* Remove Comments, Javadoc, Names of local Variables, Names of Parameters,
* Several Graphical interfaces, available on the web site.

=== How to prevent your Java code to be Reverse-engineered ? ===

Several actions can be taken for preventing reverse-engineering :

* Code Obfuscation. This is done mainly through variable renaming; see next paragraph for more precisions,
* Suppression of End Of File Characters. This makes the code difficult to parse,
* Use of anonymous classes for handling events. This seems not to be handled by many Decompiler; however, JAD copes pretty well with this.
* File encoding. This implies some overhead for uncyphering at runtime. Several tools are available:: [http://www.cinnabarsystems.com/canner.html Canner], by Cinnabar Systems, or [http://www.jbitsoftware.com/JBit/do/displayPage?targetPageId=products.jlockinfo JLock by JSoft]. They are available for evaluation, and the first is proposed currently for Windows Platforms only.

=== What tools do exists for Obfuscation ? ===

A lot of tools exist for Java code Obfuscation. You can find extensive lists under following URLs, or simply type 'obfuscator' in your favorite search engine :

* http://directory.google.com/Top/Computers/Programming/Languages/Java/Development_Tools/Obfuscators/
* http://proguard.sourceforge.net/alternatives.html

Among those projects, some are open source project, and therefore more suitable for research - but also for enterprises who wish to control the programs they use (without any warranty):

* [http://proguard.sourceforge.net/ Proguard] is a shrinker (make code more compact), and optimizer and obfuscator.
* [http://jode.sourceforge.net/ Jode] is a decompiler, an optimizer and an obfuscator. It contains facilities for cleaning logging statements,,
* [http://jarg.sourceforge.net/ Jarg],
* [http://sourceforge.net/projects/javaguard/ Javaguard], which is a simple obfuscator, without many documentation,
* [http://www.geocities.com/CapeCanaveral/Hall/2334/Programs/cafebabe.html CafeBabe], which allows precise view of Bytecode files and single file obfuscation; a good tool for teaching ByteCode Structure, more than a production tool.

== Using Proguard ==

The following section provides a short tutorial for using [http://proguard.sourceforge.net/ Proguard].

First, download the code under [http://sourceforge.net/project/showfiles.php?group_id=54750 following url ] and unzip it.

For this tutorial, we use the [http://www.rzo.free.fr/applis/genericFrame.jar genericFrame.jar package], part of [http://www.rzo.free.fr/development.php a simple demo application ].

Go tothe main directory of Proguard. For lauching it, you can use following script with given parameters :

java -jar lib/proguard.jar @config-genericFrame.pro

config-genericFrame.pro is the option file :

-obfuscationdictionary ./examples/dictionaries/compact.txt
-libraryjars /usr/java/j2sdk1.4.2_10/jre/lib/rt.jar
-injars genericFrame.jar
-outjar genericFrameOut.jar
-dontshrink
-dontoptimize
-keep public class proguard.ProGuard {
public static void main(java.lang.String[]);
}

Remark that the 'keep' option is mandatory, we use this default class for not keep anything out.

The example dictionnary (here compact.txt) is given with the code.

The output is stored in the package 'genericFrameOut.jar'.

You can observe the modifications implied by obfuscation with following commands :

jar xvf genericFrameOut.jar
cd genericFrame/pub/gui/
jad c.class
more c.jad more c.jad

Remark than Strings are kept unmodified. If you want you code to be hard to read, do not forget to remove any debugging and logging comments. Jode has some facilities for making this easier.

== Using CafeBabe ==

CafeBabe is a convenient tool for teaching structure of ByteCode files. You can [http://www.geocities.com/CapeCanaveral/Hall/2334/programs.html download it at this URL].

Unzip it and execute following command :
java -classpath CafeBabe.jar org.javalobby.apps.cafebabe.CafeBabe

Have a look at some class from the original genericFrame.jar package.

Then obfuscate it, and compare both - original and modified class :

* with the CafeBabe viewer,
* after decompiling it with JAD.

What conclusion can you draw of it ?

== Using Jode ==

Jode is to be found [http://jode.sourceforge.net/ here].

== Links ==

Bytecode obfuscation

2006-11-15T08:10:15Z

Pparrend: /* Using Proguard */

== Principles ==

Java is a language which code is quite intuitive to read. But some also complain that compiled code is as easy to read as source code - or at least it is easy to recover. You will find here a couple of hints and tips about this matter of fact, and how to deal with it if you need to prevent people to exploit code they should not work with.

=== How to recover Source Code from Bytecode? ===

The main program for uncompiling code is [http://www.kpdus.com/jad.html JAD (JAva Decompiler)]. It provides following advantages :

* Recover code from Java ByteCode,
* Get clean code for your own programs,
* Remove Comments, Javadoc, Names of local Variables, Names of Parameters,
* Several Graphical interfaces, available on the web site.

=== How to prevent your Java code to be Reverse-engineered ? ===

Several actions can be taken for preventing reverse-engineering :

* Code Obfuscation. This is done mainly through variable renaming; see next paragraph for more precisions,
* Suppression of End Of File Characters. This makes the code difficult to parse,
* Use of anonymous classes for handling events. This seems not to be handled by many Decompiler; however, JAD copes pretty well with this.
* File encoding. This implies some overhead for uncyphering at runtime. Several tools are available:: [http://www.cinnabarsystems.com/canner.html Canner], by Cinnabar Systems, [http://www.mycgiserver.com/~ipnetdevelop/katirya.html Katirya], or [http://www.jbitsoftware.com/JBit/do/displayPage?targetPageId=products.jlockinfo JLock by JSoft]. They are available for evaluation, and the two first are proposed currently for Windows Platforms only.

=== What tools do exists for Obfuscation ? ===

A lot of tools exist for Java code Obfuscation. You can find extensive lists under following URLs, or simply type 'obfuscator' in your favorite search engine :

* http://directory.google.com/Top/Computers/Programming/Languages/Java/Development_Tools/Obfuscators/
* http://proguard.sourceforge.net/alternatives.html

Among those projects, some are open source project, and therefore more suitable for research - but also for enterprises who wish to control the programs they use (without any warranty):

* [http://proguard.sourceforge.net/ Proguard] is a shrinker (make code more compact), and optimizer and obfuscator.
* [http://jode.sourceforge.net/ Jode] is a decompiler, an optimizer and an obfuscator. It contains facilities for cleaning logging statements,,
* [http://jarg.sourceforge.net/ Jarg],
* [http://sourceforge.net/projects/javaguard/ Javaguard], which is a simple obfuscator, without many documentation,
* [http://www.geocities.com/CapeCanaveral/Hall/2334/Programs/cafebabe.html CafeBabe], which allows precise view of Bytecode files and single file obfuscation; a good tool for teaching ByteCode Structure, more than a production tool.

== Using Proguard ==

The following section provides a short tutorial for using [http://proguard.sourceforge.net/ Proguard].

First, download the code under [http://sourceforge.net/project/showfiles.php?group_id=54750 following url ] and unzip it.

For this tutorial, we use the [http://www.rzo.free.fr/applis/genericFrame.jar genericFrame.jar package], part of [http://www.rzo.free.fr/development.php a simple demo application ].

Go tothe main directory of Proguard. For lauching it, you can use following script with given parameters :

java -jar lib/proguard.jar @config-genericFrame.pro

config-genericFrame.pro is the option file :

-obfuscationdictionary ./examples/dictionaries/compact.txt
-libraryjars /usr/java/j2sdk1.4.2_10/jre/lib/rt.jar
-injars genericFrame.jar
-outjar genericFrameOut.jar
-dontshrink
-dontoptimize
-keep public class proguard.ProGuard {
public static void main(java.lang.String[]);
}

Remark that the 'keep' option is mandatory, we use this default class for not keep anything out.

The example dictionnary (here compact.txt) is given with the code.

The output is stored in the package 'genericFrameOut.jar'.

You can observe the modifications implied by obfuscation with following commands :

jar xvf genericFrameOut.jar
cd genericFrame/pub/gui/
jad c.class
more c.jad more c.jad

Remark than Strings are kept unmodified. If you want you code to be hard to read, do not forget to remove any debugging and logging comments. Jode has some facilities for making this easier.

== Using CafeBabe ==

CafeBabe is a convenient tool for teaching structure of ByteCode files. You can [http://www.geocities.com/CapeCanaveral/Hall/2334/programs.html download it at this URL].

Unzip it and execute following command :
java -classpath CafeBabe.jar org.javalobby.apps.cafebabe.CafeBabe

Have a look at some class from the original genericFrame.jar package.

Then obfuscate it, and compare both - original and modified class :

* with the CafeBabe viewer,
* after decompiling it with JAD.

What conclusion can you draw of it ?

== Using Jode ==

Jode is to be found [http://jode.sourceforge.net/ here].

== Links ==