OWASP - User contributions [en]

User:Stephendv

2014-07-17T10:06:09Z

Stephendv:

Hi, I'm Stephen de Vries the CTO of [[http://www.continuumsecurity.net Continuum Security]] and can be reached at: stephen at continuumsecurity dot net.

Category:OWASP Java Project

2009-07-30T09:13:35Z

Stephendv: /* Project Sponsor */

==About==

The OWASP Java Project's goal is to enable Java and J2EE developers to build secure applications efficiently. See the [[OWASP Java Project Roadmap]] for more information on our plans.

==Joining the Project==

Rohyt Belani is the project lead. The project's high level roadmap can be found at the [[OWASP Java Project Roadmap]]
* Please submit your ideas for individual articles to the [[Java Project Article Wishlist]].
* If you'd like to contribute:
# visit the [[Tutorial]],
# join the [http://lists.owasp.org/mailman/listinfo/java-project mailing list]
# and pick a topic from the [[OWASP Java Table of Contents]], or suggest a new topic. 
Remember to add the tag: <nowiki>[[Category:OWASP Java Project]]</nowiki> to the end of new articles so that they're properly categorised.

==Java Security Overview==

While Java and J2EE contain many security technologies, it is not easy to produce an application without security vulnerabilities. Most application security [[:Category:Vulnerability|vulnerabilities]] apply to Java applications just like other environments. The notable exception is [[Buffer Overflow|buffer overflow]] and related issues that do not apply to Java applications.

There is a wealth of information about vulnerabilities that apply to Java and JavaEE application in the [[:Category:Vulnerability|Vulnerability]] articles here at OWASP. The articles that have specific Java examples are tagged with the [[:Category:Java|Java category]].

The goals of this project are to provide information about building, configuring, deploying, operating, and maintaining secure Java applications. We cover the following topics:

; [[OWASP Java Table of Contents#J2EE Security for Architects | J2EE Security for Architects]]
: Provides information about the design and architectural considerations for a Java web application. Common architectures such as EJB, Web Services and Spring Middle tiers are discussed.

; [[OWASP Java Table of Contents#J2EE Security for Developers | J2EE Security for Developers]]
: These articles cover dangerous Java calls and common vulnerabilities associated with them, such as Runtime.exec(), Statement.execute(), readline(), etc... The dangers of native code, dynamic code, and reflection will be discussed. We'll also talk about using tools like PMD, jlint, FindBugs, Eclipse, jad, and more. This section will also cover standard security mechanisms in the JDK, such as cryptography, logging, encryption, error handling. Securing elements of an application, such as servlets, JSPs, controllers, business logic, and persistence layers will be covered. We'll discuss handling request parameters, encoding, injection, and more. We'll also discuss the use of security mechanisms such as log4j, BouncyCastle, XML encryption, XML signature, and other technologies.

; [[OWASP Java Table of Contents#J2EE Security For Deployers| J2EE Security for Deployers]]
: These articles cover topics specifically related to the J2EE environment. We discuss minimizing the attack surface in web.xml, configuring error handlers, and performing hardening of popular J2EE application servers.

; [[OWASP Java Table of Contents#J2EE Security for Security Analysts and Testers| J2EE Security for Security Analysts and Testers]]
: These articles cover the verification, analysis, and testing of the security of J2EE applications. This section will cover using tools to find vulnerabilities, both in source code and in running applications. These articles will focus on J2EE-specific aspects of testing applications that use various common J2EE frameworks and coding patterns.

Category:OWASP Java Project

2009-07-30T09:13:11Z

Stephendv:

User:Stephendv

2009-05-26T07:08:10Z

Stephendv:

Hi, I'm Stephen de Vries a Principal Consultant at [[http://www.corsaire.com Corsaire]] and can be reached at: stephen at corsaire dot com. I'm currently co-leading the OWASP Java project with Rohyt Belani.

OWASP NYC AppSec 2008 Conference

2008-08-29T13:28:36Z

Stephendv:

= 2008 OWASP USA, NYC =
Last Update: {{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}

<center> Scroll down to see speaker agenda, and training options </center>

<center>[http://guest.cvent.com/i.aspx?4W,M3,828ca6d1-1b60-4105-8034-d344700e6956 http://www.owasp.org/images/6/61/Banner2_irfan.jpg]</center>
 
<hr>
<center>[http://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Diamond Sponsor] - [http://www.imperva.com http://www.owasp.org/images/d/de/Imperva_2color_RGB.jpg] 
 [https://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Platinum Sponsor] - [http://www.cenzic.com https://www.owasp.org/images/b/bf/CenzicLogo_RGB.gif] - [http://www.whitehatsec.com http://www.owasp.org/images/archive/4/4d/20080703021901%21Whitehat.gif] - [http://www-935.ibm.com/services/us/gbs/app/html/gbs_applicationservices.html?cm_re=masthead-_-business-_-apps-allappserv https://www.owasp.org/images/4/47/Ibm.jpg] </center> 
[http://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Gold, Silver & Other Sponsors] - [http://www.isc2.org http://www.owasp.org/images/4/45/Isc2logo.gif] - [http://www.f5.com http://www.owasp.org/images/7/7e/50px-F5_50px.jpg] - [http://www.aspectsecurity.com http://www.owasp.org/images/d/d1/Aspect_logo.gif] - [http://www.foundstone.com/us/education-overview.asp http://www.owasp.org/images/2/26/Foundstone.jpg] - [http://www.qualys.com https://www.owasp.org/images/a/ae/Qualys.gif] - [http://www.ouncelabs.com https://www.owasp.org/images/6/6e/OunceLabs_logo.jpg] - [http://www.fortify.com https://www.owasp.org/images/a/ac/Fortify.jpg] - [http://www.cigital.com/ https://www.owasp.org/images/b/be/Cigital_OWASP.GIF] - [http://www.acunetix.com https://www.owasp.org/images/e/eb/Acuneti.gif] - [http://www.accessitgroup.com https://www.owasp.org/images/6/6d/Accessit.JPG] -
[http://www.fishnetsecurity.com https://www.owasp.org/images/4/4a/Fishnet_security.png] - [http://www.arctecgroup.net http://www.owasp.org/images/b/bf/Arctec.jpg] - [http://www.airtightnetworks.net https://www.owasp.org/images/8/8b/Airtight.gif] -
[http://www.artofdefence.com https://www.owasp.org/images/d/dc/AOD_Logo.gif] -
[http://www.securityuniversity.net https://www.owasp.org/images/0/0d/Security_university.jpg] -
[http://www.breach.com https://www.owasp.org/images/9/9c/Breach_logo.gif] - [http://www.armorize.com https://www.owasp.org/images/c/ce/Armorize_Logo.png] -[http://www.barracudanetworks.com/ https://www.owasp.org/images/a/a2/Barracuda_Color_Logo.jpg] ~ [http://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf http://www.owasp.org/images/f/f8/Sponsorsm.gif]
 
<center>[https://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Sponsorship Opportunities] -- [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-PRESS Press Registration] -- [http://www.owasp.org/index.php/Member_Offers Other OWASP Member Offers] </center>
<hr>
With assistance from: [http://www.webappsec.org WASC], [http://www.nym-infragard.us NYM InfraGard], [http://aitglobal.com AITGlobal], [http://nyphp.org/index.php NYC PHP], [http://www.nycbug.org NYCBUG], [http://www.isacany.net NYC ISACA], [http://www.nymissa.org NYC ISSA] and [http://www.pace.edu Pace University] you're invited to (2) days of Seminars and Technology Pavilion from the world's best application security technology minds, (2) days of hardcore hands-on training, all held at [http://www.pace.edu/page.cfm?doc_id=16157 Pace University], located in downtown New York City at One Pace Plaza New York, NY 10038. Event Fees: $350 Members / $400 Non-Members / $200 for Students. [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference#OWASP_NYC_AppSec_2008_Training_Courses_-_September_22nd_and_23rd.2C_2008 2 days of hands on training classes] are also available.
<center>[http://guest.cvent.com/i.aspx?4W,M3,828ca6d1-1b60-4105-8034-d344700e6956 http://www.owasp.org/images/7/7f/Register.gif]
 
</center>
OWASP NYC's conference offers tracks for security and development professionals interested in learning how to secure applications and enterprises as well as organization leaders who want to learn more about the state of the appsec industry and its trends. With two days of training and two days of sessions discussing cutting edge research presented by some of the brightest people in the industry, this event is a must attend for anyone looking to improve their information security posture.

== 2008 OWASP USA, NYC Conference Schedule – Sept 24th - Sept 25th ==
<center>[http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference/speakeragreement OWASP Speaker Agreement]</center>
{| style="width:80%" border="0" align="center"
! colspan="4" align="center" style="background:#4058A0; color:white" | Day 1 – Sept 24th, 2008
|-
| style="width:10%; background:#7B8ABD" | || style="width:30%; background:#BC857A" | Track 1:
| style="width:30%; background:#BCA57A" | Track 2:
| style="width:30%; background:#99FF99" | Track 3:
|-
| style="width:10%; background:#7B8ABD" | 07:30-10:00 || colspan="3" style="width:80%; background:#C2C2C2" align="center" | '''Doors Open for Attendee/Speaker Registration & [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference#Technology_Pavilion_-_September_24th_and_25th Exhibit/Sponsor Area]'''

|-
| style="width:10%; background:#7B8ABD" | 09:00-09:45 || colspan="3" style="width:80%; background:#F2F2F2" align="center" | OWASP Version 3.0 who we are, where we are.. where we are going
''OWASP Foundation: [http://www.owasp.org/index.php/Contact Jeff Williams], [http://www.owasp.org/index.php/Contact Dinis Cruz], [http://www.owasp.org/index.php/Contact Dave Wichers], [http://www.linkedin.com/in/tombrennan Tom Brennan], [http://www.owasp.org/index.php/Contact Sebastien Deleersnyder], [http://www.owasp.org/index.php/Contact Paulo Coimbra], [http://www.owasp.org/index.php/Contact Kate Hartmann], [http://www.owasp.org/index.php/Contact Alison Shrader] & [http://www.owasp.org/index.php/Category:OWASP_Chapter#Chapter_Support_Materials all local chapter leaders]
''
|-
| style="width:10%; background:#7B8ABD" | 10:00-10:45 || style="width:30%; background:#BC857A" align="left" | [http://www.owasp.org/index.php/AppSecEU08_Trends_in_Web_Hacking_Incidents:_What%27s_hot_for_2008 Analysis of the Web Hacking Incidents Database (WHID)]
''[http://blog.shezaf.com Ofer Shezaf]''
| style="width:30%; background:#BCA57A" align="left" | [http://www.webappsecroadmap.com Web Application Security Road Map] 
''[http://joesecurity.blogspot.com Joe White]''
| style="width:30%; background:#99FF99" align="left" |[https://buildsecurityin.us-cert.gov/swa/acqwg.html DHS Software Assurance Initiatives]
''[http://www.linkedin.com/pub/0/ab/3b7 Stan Wisseman] & [http://www.linkedin.com/pub/1/439/923 Joe Jarzombek]''
|-
| style="width:10%; background:#7B8ABD" | 11:00-11:45 || style="width:30%; background:#BC857A" align="left" | Web Security Education using Open Source Tools
''Prof. Li-Chiou Chen & Chienitng Lin, [http://www.pace.edu/page.cfm?doc_id=16399 Pace Univ]''
| style="width:30%; background:#BCA57A" align="left" | Http Bot Research
''[http://www.shadowserver.org/wiki/pmwiki.php?n=Shadowserver.Mission Andre M. DiMino - ShadowServer Foundation]''
| style="width:30%; background:#99FF99" align="left" | MalSpam Research
'' [http://www.knujon.com/bios.html Garth Bruen]''
|-
| style="width:10%; background:#7B8ABD" | 12:00-13:00 || colspan="3" style="width:80%; background:#F2F2F2" align="center" | [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference/ctf Capture the Flag] Sign-Up
''LUNCH - Provided by event sponsors @ TechExpo''
|-
| style="width:10%; background:#7B8ABD" | 12:00-12:30 || style="width:30%; background:#BC857A" align="left" | Cross-Site Scripting Filter Evasion
''Alexios Fakos''
| style="width:30%; background:#BCA57A" align="left" | Framework-level Threat Analysis: Adding Science to the Art of Source-code review
''[http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-rohit-sethi Rohit Sethi] & [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-sahba-kazerooni Sahba Kazerooni]''
| style="width:30%; background:#99FF99" align="left" | Automated Web-based Malware Behavioral Analysis
''[http://www.linkedin.com/pub/3/359/b1a Tyler Hudak]''
|-
| style="width:10%; background:#7B8ABD" | 13:00-13:45 || style="width:30%; background:#BC857A" align="left" | OWASP Testing Guide - Offensive Assessing Financial Applications
'' [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-daniel-cuthbert Daniel Cuthbert]''
| style="width:30%; background:#BCA57A" align="left" | WAF ModSecurity
''[http://www.breach.com/company/executive-team/ Ivan Ristic]''
| style="width:30%; background:#99FF99" align="left" | Using Layer 8 and OWASP to Secure Web Applications
''[http://www.linkedin.com/in/davidstern2000 David Stern] & [http://www.linkedin.com/in/romangarber Roman Garber]''

|-
| style="width:10%; background:#7B8ABD" | 14:00-14:45 || style="width:30%; background:#BC857A" align="left" | Critical exploits... let us count the ways
''[http://jeremiahgrossman.blogspot.com Jeremiah Grossman] & [http://ha.ckers.org/blog/about Robert "RSnake" Hansen],''
| style="width:30%; background:#BCA57A" align="left" | [http://www.owasp.org/index.php/Security_Assessing_Java_RMI Security Assessing Java RMI]
''[http://www.linkedin.com/in/adamboulton Adam Boulton]''
| style="width:30%; background:#99FF99" align="left" | JBroFuzz 0.1 - 1.1: Building a Java Fuzzer for the Web
''[http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-SPEAKER-Yiannis_Pavlosoglou Yiannis Pavlosoglou]''
|-
| style="width:10%; background:#7B8ABD" | 15:00-15:45 || style="width:30%; background:#BC857A" align="left" |Industry Outlook Panel: ''[http://www.linkedin.com/in/markclancy Mark Clancy] EVP CitiGroup, [http://www.linkedin.com/pub/0/497/86a Jim Routh] CISO DTCC, [http://www.linkedin.com/pub/0/bb1/68a Sunil Seshadri] CISO NYSE-Euronet, [http://www.linkedin.com/pub/0/1ba/4a9 Warren Axelrod] SVP Bank of America, [http://www.linkedin.com/in/bernik Joe Bernik] SVP, RBS,[http://www.linkedin.com/pub/8/878/240 Jennifer Bayuk] Infosec Consultant & [http://www.linkedin.com/in/philvenables Philip Venables] CISO, Goldman Sachs
[http://www.linkedin.com/in/crecalde Carlos Recalde] SVP, Lehman Brothers
[http://www.linkedin.com/in/mahidontamsetti Mahi Dontamsetti] Moderator''
| style="width:30%; background:#BCA57A" align="left" | [http://www.owasp.org/index.php/Wild_Wild_Web_on_Security_Planet Wild Wild Web on Security Planet]
''[http://www.securisksolutions.com/company/execmgt.aspx Mano Paul]''
| style="width:30%; background:#99FF99" align="left" |[http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-SPEAKER-GunterOllmann Multidisciplinary Bank Attacks]
''Gunter Ollmann''
|-
| style="width:10%; background:#7B8ABD" | 16:00-16:45 || style="width:30%; background:#BC857A" align="left" | OWASP Enterprise Security API [http://www.owasp.org/index.php/ESAPI (ESAPI) Project]
'' [http://www.aspectsecurity.com/management.htm Jeff Williams]''
| style="width:30%; background:#BCA57A" align="left" | Shootout @ Blackbox Corral
''Larry Suto ''
| style="width:30%; background:#99FF99" align="left" | Case Studies: Exploiting application testing tool deficiencies via "out of band" injection
''[http://www.linkedin.com/pub/0/a91/aa2 Vijay Akasapu] & [http://www.linkedin.com/pub/9/279/381 Marshall Heilman]''
|-
| style="width:10%; background:#7B8ABD" | 17:00-17:45 || style="width:30%; background:#BC857A" align="left" | Threading the Needle:

Bypassing web application/service security controls using Encoding, Transcoding, Filter Evasion, and other Canonicalization Attacks
'' [http://www.linkedin.com/in/arianevans Arian Evans]''
| style="width:30%; background:#BCA57A" align="left" |Shhhh Don’t Tell Anybody
''[http://www.linkedin.com/in/ppetkov Petko D. Petkov]''
| style="width:30%; background:#99FF99" align="left" | [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-SPEAKER-Andres_Riancho w3af - A Framework to own the web]
''Andres Riancho''
|-
| style="width:10%; background:#7B8ABD" | 18:00-18:45 || style="width:30%; background:#BC857A" align="left" | [http://www.owasp.org/index.php/Category:OWASP_Live_CD_Project OWASP Live CD]
'' [http://www.linkedin.com/in/packetfocus Joshua Perrymon]''
| style="width:30%; background:#BCA57A" align="left" | Coding Secure w/PHP
''[http://www.linkedin.com/in/zaunere Hans Zaunere]''
| style="width:30%; background:#99FF99" align="left" | [http://www.owasp.org/index.php/Payment_Card_Data_Security_and_the_new_Enterprise_Java Payment Card Data Security and the new Enterprise Java]
''[https://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-SPEAKER-Dr._B._V._Kumar Dr. B. V. Kumar] & [https://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-SPEAKER-Abhay_Bhargav Mr. Abhay Bhargav]''
|-
| style="width:10%; background:#7B8ABD" | 20:00-23:00 || colspan="3" style="width:80%; background:#C2C2C2" align="center" | OWASP NYC AppSec 2008 VIP Party
''Location: TBD''
|-
! colspan="10" align="center" style="background:#4058A0; color:white" | Day 2 – Sept 25th, 2008
|-
| style="width:10%; background:#99FF99" | 08:00-10:00 || colspan="3" style="width:80%; background:#F2F2F2" align="center" | BREAKFAST - Provided by event sponsors @ TechExpo

|-
| style="width:10%; background:#7B8ABD" | 08:00-08:45 || style="width:30%; background:#BC857A" align="left" | Software Development: The Last Security Frontier
''[http://blog.isc2.org/isc2_blog/tipton/index.html W. Hord Tipton], CISSP-ISSEP, CAP, CISA, CNSS and former Chief Information Officer for the U.S. Department of the Interior
Executive Director and member of the Board of Directors, (ISC)²''
| style="width:30%; background:#BCA57A" align="left" | [http://www.owasp.org/index.php/AppSecEU08_Best_Practices_Guide_Web_Application_Firewalls Best Practices Guide: Web Application Firewalls]
''Alexander Meisel''
| style="width:30%; background:#99FF99" align="left" | The Good The Bad and The Ugly - Pen Testing VS. Source Code Analysis
''[http://www.linkedin.com/in/tommyryan Thomas Ryan]'' & ''[http://www.linkedin.com/in/steveantoniewicz Steve Antoniewicz]''

|-
| style="width:10%; background:#7B8ABD" | 09:00-09:45 || style="width:30%; background:#BC857A" align="left" | [http://www.trutv.com/video/tiger-team/tiger-team-101-1-of-4.html APPSEC Red/Tiger Team Projects]
''[http://www.linkedin.com/pub/1/373/994 Chris Nickerson]''
| style="width:30%; background:#BCA57A" align="left" | OWASP "Google Hacking" Project
''[http://www.linkedin.com/in/ChristianHeinrich Christian Heinrich]''
| style="width:30%; background:#99FF99" align="left" | OWASP Web Services Top Ten
''[http://1raindrop.typepad.com Gunnar Peterson]''
|-
| style="width:10%; background:#7B8ABD" | 10:00-10:45 || style="width:30%; background:#BC857A" align="left" | Lets talk about OWASP....
''Dinis Cruz''
| style="width:30%; background:#BCA57A" align="left" | "Help Wanted" [http://www.infosecleaders.com/survey 7 Things You Need to Know APPSEC/INFOSEC Employment]
''[http://www.linkedin.com/pub/0/29/685 Lee Kushner]''
| style="width:30%; background:#99FF99" align="left" | Industry Analyst with Forrester Research
''[http://www.forrester.com/rb/analyst/chenxi_wang Chenxi Wang]''
|-
| style="width:10%; background:#7B8ABD" | 11:00-11:45 || style="width:30%; background:#BC857A" align="left" | [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project CLASP (Comprehensive, Lightweight Application Security Process)]
''Pravir Chandra''
| style="width:30%; background:#BCA57A" align="left" | Next Generation Cross Site Scripting Worms
''[http://i8jesus.com/?page_id=5 Arshan Dabirsiaghi]''
| style="width:30%; background:#99FF99" align="left" | Secure Software Impact
''[http://ouncelabs.com/company/team.asp Jack Danahy]''
|-
| style="width:10%; background:#7B8ABD" | 12:00-12:45 || style="width:30%; background:#BC857A" align="left" | Security in Agile Development
''[http://www.owasp.org/index.php/User:Wichers Dave Wichers]''
| style="width:30%; background:#BCA57A" align="left" | Security of Software-as-a-Service (SaaS)
''[http://www.linkedin.com/pub/6/372/45a James Landis]''
| style="width:30%; background:#99FF99" align="left" | [http://reversebenchmarking.com/About.html Open Reverse Benchmarking Project]
''Marce Luck & [http://www.linkedin.com/pub/1/507/616 Tom Stracener]''
|-
| style="width:10%; background:#7B8ABD" | 12:00-13:00 || colspan="3" style="width:80%; background:#F2F2F2" align="center" | [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference/ctf Capture the Flag] Status
''LUNCH - Provided @ TechExpo''
|-
| style="width:10%; background:#7B8ABD" | 13:00-13:45 || style="width:30%; background:#BC857A" align="left" | Security Research Report
''[http://www.linkedin.com/pub/5/742/233 Dinis Cruz]''
| style="width:30%; background:#BCA57A" align="left" | Get Rich or Die Trying - Making Money on The Web, The Black Hat Way
''Trey Ford, Tom Brennan, Jeremiah Grossman''
| style="width:30%; background:#99FF99" align="left" | [https://www.owasp.org/index.php/User_talk:Jian Lotus Notes/Domino Web Application Security]
''[https://www.owasp.org/index.php/User_talk:Jian Jian Hui Wang]''
|-
| style="width:10%; background:#7B8ABD" | 14:00-14:45 || style="width:30%; background:#BC857A" align="left" | Practical Advanced Threat Modeling
''John Steven''
| style="width:30%; background:#BCA57A" align="left" | [http://www.owasp.org/index.php/Category:OWASP_Orizon_Project The Owasp Orizon Project: towards version 1.0]
[https://www.owasp.org/index.php/User:Thesp0nge Paolo Perego]
| style="width:30%; background:#99FF99" align="left" | [http://www.owasp.org/index.php/Building_Usable_Security Building Usable Security]
[http://www.owasp.org/index.php/Zed_Abbadi Zed Abbadi]
|-
| style="width:10%; background:#7B8ABD" | 15:00-15:45 || style="width:30%; background:#BC857A" align="left" | [http://www.owasp.org/index.php/Input_validation:_the_Good%2C_the_Bad_and_the_Ugly Input validation: the Good, the Bad and the Ugly]
''[http://johanpeeters.com Johan Peeters]''
| style="width:30%; background:#BCA57A" align="left" | Off-shoring Application Development? Security is Still Your Problem
''Rohyt Belani''
| style="width:30%; background:#99FF99" align="left" | [[NIST SAMATE Static Analysis Tool Exposition (SATE)]]
''[http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-vadim-okun Vadim Okun]''
|-
| style="width:10%; background:#7B8ABD" | 16:00-16:45 || style="width:30%; background:#BC857A" align="left" | Vulnerabilities in application interpreters and runtimes
''Erik Cabetas''
| style="width:30%; background:#BCA57A" align="left" | Flash Parameter Injection (FPI)
''Ayal Yogev & Adi Sharabani''
| style="width:30%; background:#99FF99" align="left" | Mastering PCI Section 6.6
''[http://www.linkedin.com/pub/1/228/6a5 Taylor McKinley] and [http://www.linkedin.com/in/jacobwest Jacob West]''
|-
| style="width:10%; background:#7B8ABD" | 17:00-17:45 || colspan="3" style="width:80%; background:#C2C2C2" align="center" | '''Wizdom of Crowds / CTF Awards & Raffles'''
|-
| style="width:10%; background:#7B8ABD" | 18:30-19:30 || colspan="3" style="width:80%; background:#C2C2C2" align="center" | OWASP Foundation, Chapter Leader Meeting
|}

<center>[http://guest.cvent.com/i.aspx?4W,M3,828ca6d1-1b60-4105-8034-d344700e6956 http://www.owasp.org/images/7/7f/Register.gif]</center>

== Technology Pavilion - September 24th and 25th ==

Want to see the latest offerings from technology product and service firms, visit the Technology Pavilion. On September 24th and 25th. 2 full days of exhibits by service providers and manufacturers from around the world.

Do you want to preview the event space [http://www.flickr.com/photos/21550725@N04/sets/72157604662279903/detail Click Here]

<hr>

== CPE Credits ==

Much of the content is eligible for CPE credits. Please check with your institution regarding specific requirements.

'''The CISM cpe policy (www.isaca.org/cismcpepolicy) states''':

One continuing professional education hour is earned for each fifty minutes of active participation (excluding lunches and breaks) in a professional educational activity. Continuing professional education hours are only earned in full-hour increments and rounding must be down. For example, a CISA who attends an eight-hour presentation (480 minutes) with 90 minutes of breaks will earn seven (7) continuing professional education hours.

Activities that qualify for CPE must be directly applicable to the management, design or assessment of an enterprise's information security as per the CISM job practice"

'''Earn (ISC)2 CPE Credits at 2008 OWASP USA, NYC'''

Attendance at the 2008 OWASP NYC Training Courses or Conferences will earn you Continuing Professional Education (CPE) credits as follows:
Training Courses: September 22-23, 2008
• 16 CPE units for 2 days of training (Monday - Tuesday)
• 8 CPE units for 1 day of training (Monday or Tuesday Only)
Conferences: September 24-25, 2008
Earn 1 CPE per hour of conference attendance

== [http://www.owasp.org/index.php/Category:OWASP_AppSec_Conference_Training OWASP NYC AppSec 2008 Training Courses - September 22nd and 23rd, 2008] ==
{| style="width:80%" border="0" align="center"
! align="center" style="background:#4058A0; color:white" | T1. Defensive Programming - 2-Days - $1350
|-
| style="background:#F2F2F2" | This class will teach you how to program defensively. A must for developers, managers, testers and security professionals. Learn the latest techniques to build attack resistant code, protect from current and future vulnerabilities and how to secure an application from both implementation bugs and design flaws. The instructor Pravir Chandra is well known security expert, project lead for OWASP CLASP project and former co-founder & CTO of secure software [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]

Instructor: Jason Rouse, Technical Manager, [http://www.cigital.com/training/series http://www.owasp.org/images/b/be/Cigital_OWASP.GIF]'''
|-
{| style="width:80%" border="0" align="center"
! align="center" style="background:#4058A0; color:white" | T2. Secure Coding for Java EE - 2-Days - $1350
|-
| style="background:#F2F2F2" | This course is similar to Aspect's Building and Testing Secure Web Applications except it includes a significant amount of Java focused content, including:
# Java EE security overview,
# All coding examples and recommendations are specifically focused on Java and Java servers, and
# 3 additional hands on coding labs where the students find and then fix security vulnerabilities in a Java EE application developed for the class.

[[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]

Instructor: Dave Wichers: [http://www.aspectsecurity.com http://www.owasp.org/images/d/d1/Aspect_logo.gif]
'''
|-
! align="center" style="background:#4058A0; color:white" | T3. Web Services and XML Security - 2-Days - $1350
|-
| style="background:#F2F2F2" | The movement towards Web Services and Service Oriented architecture (SOA) paradigms requires new security paradigms to deal with new risks posed by these architectures. This session takes a pragmatic approach towards identifying Web Services security risks and selecting and applying countermeasures to the application, code, web servers, databases, application, and identity servers and related software. [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]

Instructor: Gunnar Peterson''' [http://www.arctecgroup.net https://www.owasp.org/images/b/bf/Arctec.jpg]
|-
! align="center" style="background:#4058A0; color:white" | T4. Advanced Web Application Security Testing - 2-Days - $1350
|-
| style="background:#F2F2F2" | Course Overview While all developers need to know the basics of web application security testing, application security specialists will want to know all the advanced techniques for finding and diagnosing security problems in applications. Aspect’s Advanced Web Application Security Testing training is based on a decade of work verifying the security of critical applications. The course is taught by an experienced application security practitioner in an interactive manner. [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]

Instructor: Eric Sheridan: [http://www.aspectsecurity.com http://www.owasp.org/images/d/d1/Aspect_logo.gif]'''
|-
! align="center" style="background:#4058A0; color:white" | T5. Leading the Development of Secure Applications 1-Day - Sept 22nd- $675
|-
| style="background:#F2F2F2" | In this one-day management session you’ll get the answers to the ten key questions that most CIOs and development managers face when trying to improve security in the development process. The course provides proven techniques and valuable lessons learned that can be applied to projects at any phase of their application’s lifecycle. [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]
Instructor: John Pavone: [http://www.aspectsecurity.com http://www.owasp.org/images/d/d1/Aspect_logo.gif]'''
|-
{| style="width:80%" border="0" align="center"
|-
! align="center" style="background:#4058A0; color:white" | T6. Building Secure Rich Internet Applications 1-Day - Sept 23rd- $675
|-
| style="background:#F2F2F2" | Rich Internet applications using technologies like Ajax, Flash, ActiveX, and Java Applets require special attention to secure. This one day training addresses the special issues that arise in this type of application development. [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]
Instructor: Arshan Dabirsiaghi: [http://www.aspectsecurity.com http://www.owasp.org/images/d/d1/Aspect_logo.gif]'''
|-
{| style="width:80%" border="0" align="center"

! align="center" style="background:#4058A0; color:white" | T8. Writing Secure Code ASP.NET - 2-Days - $1350
|-
| style="background:#F2F2F2" | Understand the key security features of the .NET platform, the common web security pitfalls developers make, and how to build secure and reliable web applications using ASP.NET. Students are lead through hands on code examples that highlight issues and prescribe solutions. [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]

The instructors are Foundstone's Technical Director, Rudolph Araujo and Foundstone's Professional Services Conlultant, Alex Smolen. [http://www.foundstone.com/us/education-overview.asp https://www.owasp.org/images/2/26/Foundstone.jpg]
|}
<center>[http://guest.cvent.com/i.aspx?4W,M3,828ca6d1-1b60-4105-8034-d344700e6956 https://www.owasp.org/images/7/7f/Register.gif]</center>

<h2> HOTELS / TRAVEL </h2>
[http://maps.google.com/maps?near=Pace+Plz,+New+York,+NY+10038+(Pace+University+New+York+Cmps)&geocode=15467452012610799558,40.711640,-74.005820&q=hotel&f=l&dq=Pace+University-New+York&ie=UTF8&z=15&om=0 Hotels in the area of the event]

New York City MTA: http://www.mta.nyc.ny.us/nyct/index.html

New York City Subway & walking directions: http://www.hopstop.com/?city=newyork

New York Sights & Sounds - SightsSounds

New York City Travel Guide - http://www.nytoday.com/

New York City Attractions - http://www.nycvisit.com

New York TV Show Tickets - Get free tickets to TV shows! - http://www.nytix.com/

New York City local news: http://www.ny1news.com

<h2>EVENT SPONSORSHIP </h2>The OWASP Conferences & Training security technologists including CSOs,admins, application admins, MIS directors, homeland defense chiefs. These important influencers drive buying decisions exclusive access to its audiences. OWASP has established strategic relationships with security—print publications, newsletters, portals, consultants,message—and leadership positioning OWASP events. OWASP’s mission is supported by organizations who share our application, and software security communities. This approach should be part of your mix.

[https://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Sponsorship Opportunities]- Register online: [http://guest.cvent.com/i.aspx?4W,M3,09e3b490-ba93-4474-851e-be803b1a01c2 click here]

Security Assessing Java RMI

2008-08-29T13:25:25Z

Stephendv: New page: == Introduction == The talk will describe the process for performing a security assessment on Java RMI services, including identifying and making unauthorised calls to the service. There ...

== Introduction ==
The talk will describe the process for performing a security assessment on Java RMI services, including identifying and making unauthorised calls to the service. There are currently no available tools to perform object and method identification. The techniques described in this talk will be used together with an innovative prototype for an RMI assessment tool to demonstrate how an RMI service can be interrogated and manipulated from a zero knowledge perspective.

== Outline ==
* Introduction to Java RMI - What is RMI, how and where is it used.
* RMI Architecture - How are RMI Client/Server applications structured and what is exposed?
* Objectives of assessing RMI:
** Identify the objects and methods that are exposed
** Make arbitrary calls to those methods.
* Enumerating bound objects - supported by the standard RMI API
* Enumerating remote methods - Methods are not exposed, but they can still be obtained!
** Using existing method signatures
** Sniffing the wire
** Brute force - is realistically feasible
* Determining the number of parameters
* Determining parameter type
* Calling remote methods
* Fuzzing
* Securing RMI
** Network controls
** Security on the server
** Secure coding of the exposed methods

== About the Author ==
Adam Boulton is a Research Developer and Security Consultant for Corsaire. He has been involved in all aspects on the SDLC with a focus upon security. He graduated from Sheffield Hallam University with a 1st Class Software Engineering Degree and is also certified for secure code assessments.
Adam’s past roles have included that of a Software Engineer for the Ministry of Defence and a Virus Analyst for Sophos Plc. At both positions he was heavily involved in Software Development, Reverse Engineering and implementing security.

Talk:Password length & complexity

2008-03-25T12:45:07Z

Stephendv: Removing all content from page

Category:OWASP CSRFGuard Project

2008-03-10T16:47:23Z

Stephendv:

==Overview==

Just when developers are starting to run in circles over [[Cross Site Scripting]], the [http://www.darkreading.com/document.asp?doc_id=107651&WT.svl=news1_2 'sleeping giant'] awakes for yet another web-catastrophe. [[Cross-Site Request Forgery]] (CSRF) is an attack whereby the victim is tricked into loading information from or submitting information to a web application for which they are currently authenticated. The problem is that the web application has no means of verifying the integrity of the request. The OWASP CSRFGuard Project attempts to address this issue through the use of unique request tokens.

[http://www.owasp.org/index.php/How_CSRFGuard_Works Click here] for more information regarding the design and implementation of CSRFGuard.

==CSRF Testing Tool==

Check out the [http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project OWASP CSRF Tester] tool which allows you to test for CSRF vulnerabilities. This tool is also written in Java.

==License==

CSRFGuard is offered under the [http://www.gnu.org/copyleft/lesser.html LGPL]. For further information on OWASP licenses, please consult the [[OWASP Licenses]] page.

== Downloads ==

=== Version 1===

[http://www.owasp.org/index.php/Image:CSRF_Guard.zip Click here] to download the latest version of the OWASP CSRFGuard 1.x series.

=== Version 2===

[http://www.owasp.org/index.php/Image:OWASP-CSRFGuard-2.0.jar Click here] to download the latest OWASP CSRFGuard 2.0 binary.

[http://www.owasp.org/index.php/Image:OWASP_CSRFGuard-2.0-src.zip Click here] to download the latest OWASP CSRFGuard 2.0 source, binary, and sample configuration files '''(Recommended)'''.

[http://www.owasp.org/images/c/c9/CSRF_DangerDetectionDefenses.ppt Click here] to download the author's presentation at the 2007 OWASP conference in San Jose about the dangers of CSRF and a brief description of both CSRF Guard and CSRF Tester.

== Installation Instructions ==

[http://www.owasp.org/index.php/CSRFGuard_1.x_Installation Click here] to view the installation instructions of the OWASP CSRFGuard 1.0 series.

[http://www.owasp.org/index.php/CSRFGuard_2.x_Installation Click here] to view the installation instructions of the OWASP CSRFGuard 2.0 series.

== Road Map ==

[https://www.owasp.org/index.php/CSRF_Guard_2x_Roadmap Click here] to view the road map for the latest development version of CSRFGuard. Please feel free to add your own change requests or send me patches/diffs!

==Feedback and Participation ==

We hope you find CSRFGuard useful. Please contribute back to the project by sending your comments, questions, and suggestions to OWASP. Thanks!

==Similar Projects==

There are a small number of other projects that implement the unique random request token concept similar to that of CSRFGuard. They are as follows:

:*http://www.owasp.org/index.php/PHP_CSRF_Guard
:*http://www.thespanner.co.uk/2007/10/19/jsck/

==Donations==

The Open Web Application Security Project is purely an open-source community driven effort. As such, all projects and research efforts are contributed and maintained with an individual's ''spare time.'' If you have found this or any other project useful, please support OWASP with a [https://www.owasp.org/index.php/Contributions donation].

==Project Sponsors==

The OWASP CSRFGuard project is sponsored by [http://www.aspectsecurity.com https://www.owasp.org/images/d/d1/Aspect_logo.gif].

[[Category:OWASP_Validation_Project]]
[[Category:Java]]
[[Category:OWASP_Project]]
[[Category:OWASP_Java_Project]]

Preventing LDAP Injection in Java

2008-03-10T16:33:06Z

Stephendv: /* Status */

==Status==
Needs to be reviewed

==Approach==
The best way to prevent LDAP injection is to use a positive validation scheme for ensuring that the data going into your queries doesn't contain any attacks. You can read more in [[:Category:OWASP Guide Project|the OWASP Guide]] about input validation.

However, in some cases, it is necessary to include special characters in input that is passed into an LDAP query. In this case, using escaping can prevent the LDAP interpreter from thinking those special characters are actually LDAP query. Rather, the encoding lets the interpreter treat those special characters as data.

Here are a few methods for escaping certain meta-characters in LDAP queries. Both the distinguished name (DN) and the search filter have their own sets of meta-characters. In the case of Java, it is also necessary to escape any JNDI meta-characters, since java uses JNDI to perform LDAP queries.

public static String escapeDN(String name) {
StringBuffer sb = new StringBuffer(); // If using JDK >= 1.5 consider using StringBuilder
if ((name.length() > 0) && ((name.charAt(0) == ' ') || (name.charAt(0) == '#'))) {
sb.append('\\'); // add the leading backslash if needed
}
for (int i = 0; i < name.length(); i++) {
char curChar = name.charAt(i);
switch (curChar) {
case '\\':
sb.append("\\\\");
break;
case ',':
sb.append("\\,");
break;
case '+':
sb.append("\\+");
break;
case '"':
sb.append("\\\"");
break;
case '<':
sb.append("\\<");
break;
case '>':
sb.append("\\>");
break;
case ';':
sb.append("\\;");
break;
default:
sb.append(curChar);
}
}
if ((name.length() > 1) && (name.charAt(name.length() - 1) == ' ')) {
sb.insert(sb.length() - 1, '\\'); // add the trailing backslash if needed
}
return sb.toString();
}

Escaping the search filter:

public static final String escapeLDAPSearchFilter(String filter) {
StringBuffer sb = new StringBuffer(); // If using JDK >= 1.5 consider using StringBuilder
for (int i = 0; i < filter.length(); i++) {
char curChar = filter.charAt(i);
switch (curChar) {
case '\\':
sb.append("\\5c");
break;
case '*':
sb.append("\\2a");
break;
case '(':
sb.append("\\28");
break;
case ')':
sb.append("\\29");
break;
case '\u0000':
sb.append("\\00");
break;
default:
sb.append(curChar);
}
}
return sb.toString();
}

Test class:

//escapeDN
assertEquals("No special characters to escape", "Helloé", escapeDN("Helloé"));
assertEquals("leading #", "\\# Helloé", escapeDN("# Helloé"));
assertEquals("leading space", "\\ Helloé", escapeDN(" Helloé"));
assertEquals("trailing space", "Helloé\\ ", escapeDN("Helloé "));
assertEquals("only 3 spaces", "\\ \\ ", escapeDN(" "));
assertEquals("Christmas Tree DN", "\\ Hello\\\\ \\+ \\, \\\"World\\\" \\;\\ ", Test.escapeDN(" Hello\\ + , \"World\" ; "));

assertEquals("No special characters to escape", "Hi This is a test #çà", SecTool.escapeLDAPSearchFilter("Hi This is a test #çà"));
assertEquals("LDAP Christams Tree", "Hi \\28This\\29 = is \\2a a \\5c test # ç à ô", SecTool.escapeLDAPSearchFilter("Hi (This) = is * a \\ test # ç à ô"));

[[Category:OWASP Java Project]]

Preventing LDAP Injection in Java

2008-03-10T16:32:31Z

Stephendv: /* Author */

Preventing LDAP Injection in Java

2008-03-10T16:16:04Z

Stephendv: /* Approach */

==Status==
'''Broken code! Needs to be corrected.'''

==Author==
==Approach==
The best way to prevent LDAP injection is to use a positive validation scheme for ensuring that the data going into your queries doesn't contain any attacks. You can read more in [[:Category:OWASP Guide Project|the OWASP Guide]] about input validation.

However, in some cases, it is necessary to include special characters in input that is passed into an LDAP query. In this case, using escaping can prevent the LDAP interpreter from thinking those special characters are actually LDAP query. Rather, the encoding lets the interpreter treat those special characters as data.

Here are a few methods for escaping certain meta-characters in LDAP queries. Both the distinguished name (DN) and the search filter have their own sets of meta-characters. In the case of Java, it is also necessary to escape any JNDI meta-characters, since java uses JNDI to perform LDAP queries.

public static String escapeDN(String name) {
StringBuffer sb = new StringBuffer(); // If using JDK >= 1.5 consider using StringBuilder
if ((name.length() > 0) && ((name.charAt(0) == ' ') || (name.charAt(0) == '#'))) {
sb.append('\\'); // add the leading backslash if needed
}
for (int i = 0; i < name.length(); i++) {
char curChar = name.charAt(i);
switch (curChar) {
case '\\':
sb.append("\\\\");
break;
case ',':
sb.append("\\,");
break;
case '+':
sb.append("\\+");
break;
case '"':
sb.append("\\\"");
break;
case '<':
sb.append("\\<");
break;
case '>':
sb.append("\\>");
break;
case ';':
sb.append("\\;");
break;
default:
sb.append(curChar);
}
}
if ((name.length() > 1) && (name.charAt(name.length() - 1) == ' ')) {
sb.insert(sb.length() - 1, '\\'); // add the trailing backslash if needed
}
return sb.toString();
}

Escaping the search filter:

public static final String escapeLDAPSearchFilter(String filter) {
StringBuffer sb = new StringBuffer(); // If using JDK >= 1.5 consider using StringBuilder
for (int i = 0; i < filter.length(); i++) {
char curChar = filter.charAt(i);
switch (curChar) {
case '\\':
sb.append("\\5c");
break;
case '*':
sb.append("\\2a");
break;
case '(':
sb.append("\\28");
break;
case ')':
sb.append("\\29");
break;
case '\u0000':
sb.append("\\00");
break;
default:
sb.append(curChar);
}
}
return sb.toString();
}

Test class:

//escapeDN
assertEquals("No special characters to escape", "Helloé", escapeDN("Helloé"));
assertEquals("leading #", "\\# Helloé", escapeDN("# Helloé"));
assertEquals("leading space", "\\ Helloé", escapeDN(" Helloé"));
assertEquals("trailing space", "Helloé\\ ", escapeDN("Helloé "));
assertEquals("only 3 spaces", "\\ \\ ", escapeDN(" "));
assertEquals("Christmas Tree DN", "\\ Hello\\\\ \\+ \\, \\\"World\\\" \\;\\ ", Test.escapeDN(" Hello\\ + , \"World\" ; "));

assertEquals("No special characters to escape", "Hi This is a test #çà", SecTool.escapeLDAPSearchFilter("Hi This is a test #çà"));
assertEquals("LDAP Christams Tree", "Hi \\28This\\29 = is \\2a a \\5c test # ç à ô", SecTool.escapeLDAPSearchFilter("Hi (This) = is * a \\ test # ç à ô"));

[[Category:OWASP Java Project]]

Talk:Password length & complexity

2008-03-10T16:06:28Z

Stephendv: New page: The OWASP Guide project is the place for generic recommendations for implementing security. What we need for this article is code examples on how to provide password length and complexity...

The OWASP Guide project is the place for generic recommendations for implementing security. What we need for this article is code examples on how to provide password length and complexity solution in Java.

Java Server Faces

2008-03-10T15:53:06Z

Stephendv: /* Web security.. before you start */

==Status==
Under review 10/3/2008

==Web security.. before you start ==

This document is about security in web applications developed using the Java Server Faces (JSF) framework. The reader should be aware of the meaning of common terms of both JSF (converters, validators, managed beans) and web security (injection etc.)

==JSF Standards and roles==
JavaServer Faces (JSF) is a Java-based Web application framework that implements the Model-View-Controller pattern and simplifies the development of web interfaces for Java EE applications.

In a standard MVC JSF are meant to provide the V (of view) and part of the C (of Control). JSF components can present almost any basic interface model. The framework also provides part of the Control layer including:
* Navigation Handling
* Error Handling
* Action and event Management
* Input validation
* Value conversion
These elements are defined by the JSF standard (JCP 127) so that any attacker will have knowledge of the architecture and life cycle of a JSF based application. JSF does not implement it's own security model but instead relies on standard JEE security. This means that both application server security model, JAAS or other ACL implementations can be used with the JSF framework without any integration effort. But Access Control is just one part of security - all aspects should be implemented in a secure manner in order to consider the application itself secure.

==Client-side state saving==
A JSF application can save the state of its components in the client response or on the server. Saving state on the client may be required because some users turn off cookies support, but it can increase response times when connections are slow. Saving state on the server may have the disadvantage of high memory consumption for the user, but it does minimize bandwidth requirements.
Since client-side state saving stores data in the client , it should be used wisely, or not used at all. An attacker that can manipulate a user's data could manage a data tampering or worst, a privilege escalation exploit. Unencrypted data is quite easy to manipulate and most of the client-side saved data are serialized Java objects which can contain a wealth of sensitive data. If you plan to use client-side state saving carefully consider which information you decide to store in the POJO/DTO in order to minimise these risks.
==Components==
===Converters===
Converter could be a source of threat since it converts string in Java objects. An attacker could inject malicious code or tampered data to make the converter itself misbehave and expose protected data. The converter system is not insecure by itself, but conversion, since it is a security touch point for business logic and persistent data, should be handled carefully. Input should '''always''' be validated '''after''' being converted. In JSF lingo you should '''always''' have a validator if a conversion occurs. See next section on how to implement a security aware validator.

===Validators===
Validation is your chance to verify that the input is as expected. This means that the input should be validated both from a domain view and from a security view. If input represents a string that in your domain should be from 10 to 254 characters long, the same string should be validated also to prevent SQL Injection and XSS attacks. Since many security checks are done using dictionary algorithms it's useful to have a validator that implements those checks and extends it to implement your domain validator.
For example:

public class TenToHundredsValidator extends SecureValidator() {
public void validate(...) {

super.validate(...); // Do security checks

domainvalidate(....);
}
}

===ManagedBeans===
Managed beans are the gears of JSF based application. Developers can access FacesContext statically and this is potentially dangerous. This is a common short cut for everything in the JSF layer, but manipulating this data could be harmful. Relying on security principals, and software engineering, is always a good approach.
Calls such as:
FacesContext.getCurrentInstance().getExternalContext().getRequestParameter("name")
are dangerous because the whole validation stack is bypassed. You can read parameters but consider them as tainted input. Use Validators described above also if you are not in the validation phase . Validators are also an effective way to refactor your validation code and to prevent code repetition.
FacesContext also allows access to user principal data; this data could be used to verify if the current user can actually execute the business logic in the managed Bean.
This practice should be adopted in favour of rendering or not the commandLinks that lead to the action of the managed Bean. A structured adoption of an execution based security framework , such as ACEGI (see the Appendix), could be a good enforcement of the security of the managed bean.
===Custom components===
If the use of custom components is required in the application, the security depends on how the components are developed. Third party components should be delivered with a security report and support from the specific vendor or community.
If you develop custom components you should be aware of the same old security issues of web development:
* Do not trust request parameter
* Do not trust cookies
* Always consider that session could be hijacked
Since the component tree is assembled server side it can be trusted so if your custom component needs to read data from a sibling component it should be considered a safe operation although you will have to make assumptions on element names of the tree.

==Implementations==
Since more than one JSF Implementation exists, bugs of the implementation should be first on the security list.

===MyFaces===
There aren't major or critical security bugs registered in the current stable release of MyFaces (1.1.5). Client state saving is still the weak point and should be used wisely. My Faces comes also with a Security Extension (http://wiki.apache.org/myfaces/SecurityContext) that allows to safely and easily retrieve authenticated user details.

The MyFaces resource filter could be a source of threat. It is designed to expose resources from a jar file and could therefore, be considered, potentially dangerous. Note there aren't any claimed security flaws nor exploits in the resource filter, but the nature of this component makes it a good target for attackers. Since all it has to do is serve data it is recommended that a dispatcher be added to the filter mapping element. This should lower the possibility of an attacker successfully manipulating the server request.
For more information see: http://myfaces.apache.org/tomahawk/extensionsFilter.htm

There is also an easy way to enable encryption when using ''client save state''

<context-param>
<param-name>org.apache.myfaces.secret</param-name>
<param-value>NzY1NDMyMTA=</param-value>
</context-param>

Supported encryption methods are BlowFish, 3DES, AES and are definde bya a context parameter

<context-param>
<param-name>org.apache.myfaces.algorithm</param-name>
<param-value>Blowfish</param-value>
</context-param>

You can find mre info at http://wiki.apache.org/myfaces/Secure_Your_Application

===SUN Reference Implementation===
Quoting from the documentation:
''There are several ways for a web application to store session state on the client tier. One possible solution is to use Cookies to store the state on the client. However, cookies have limitations in size and are not ideal in cases where you want to store session state on the client. The state that needs to be stored on the client is first serialized into a byte array. This byte array is then encrypted using industrial-strength 3DES with cipher-block-chaining (CBC) and an initialization vector. To make the content tamper-resistant, we then create a message authentication code (using SHA1 algorithm) from the encrypted content and the initialization vector. The initialization vector, the message authentication code, and the encrypted content is then combined in a single byte array. Finally, this resulting byte array is converted into a base64 string which is stored in a hidden FORM field on the client.
This solution is secure because it uses a strong crypto algorithm and also uses a MAC for tamper-resistance. We also generate all the random numbers (for example, to generate the initialization vectors and the password) using the cryptographically-secure SecureRandom class. Note that the encryption keys are NEVER sent to the client or sent on the wire. These keys are used only on the server-side to encrypt and decrypt the state. One challenge is to decide what encryption keys to use. The encryption keys should not be known to the client, but still be associated with the client. We solve this problem by generating these keys from a password that is generated randomly and stored in the HttpSession. This strategy for key generation through password is pluggable in our solution and can be changed if needed.''

===ICE Faces===

Starting from the idea that AJAX on Its Own Doesn't Corrupt Web Security ICE faces implements a component suite with ajax support by maintainig a coninus sync bettween the dom sent to the browser and a dom rapresentation on the server. javascript is used to send commands to the server and invoke the logic in the java layer. Since dom model and javascript is involved a Javascript debugging tool with value injection or dom injection capability could be of some use in pick loking the app.

As stated in ICEFaces manual " the client is untrusted, SO DON'T TRUST IT!!" : it means that is all ups to the application designer to implement a robust security logic behind the scenes.
In another point of view th developer could focus on implement server side security since with the server-side-dom architecture the thin client is even thinner.

The component thath refresh the two dom , caled IntervalRenderer, uses a persistent ServletRequest stored on the server. Unfortunately, this request does not contain sufficient information to perform the isUserInRole() check.
This kind of check is possible only on stadar render request phase.

To address this, a small amount of integration will be required either between ICEfaces and acegi-security or ICEfaces and the application server. Acegi-security (see appendix one ) is likely preferable as it will be more portable.

==Apendix I==

===ACEGI Integration===

Acegi Security is a powerful, flexible security solution for enterprise software, with a particular emphasis on applications that use Spring. If used in combination with jsf, the managed beans could become more "security aware" since acegi do not only perform authentication but also authorization in business layer. Acegi is a convenient way to manage security in all the layers of our application. This is a valuable thing especially when authorization is strongly coupled with business logic (approval work flows etc).

In order to use a custom JSF-Acegi login we have to provide a valid Security Context (''userName'' and ''password'' are properties of the managed bean)

UsernamePasswordAuthenticationToken authReq = new UsernamePasswordAuthenticationToken(userName, password);
Authentication auth = getAuthenticationManager().authenticate(authReq);
SecurityContext secCtx = SecurityContextHolder.getContext();
secCtx.setAuthentication(auth);

We can override the standard ACEGI navigation with custom, logic driven, navigation reading security context and routing the outcome.

More information can be found at here [http://www.javakaffee.de/blog/2006/07/04/jsfacegi-authentication-with-a-backing-bean/]

ACEGI can be integrated also in the rendering via custom components [http://cagataycivici.wordpress.com/2006/01/19/acegi_jsf_components_hit_the/] which basically wrap the standard ACEGI tag library in JSF components. This conveniently solve the ''stage zero'' of profiling: display or not a widget in the page.

Including a JSF based form for login in a page could be a little tricky, bu using MyFaces tomahawk components it can be done easely.

The form will look like

<%@ taglib uri="http://myfaces.apache.org/tomahawk" prefix="t"%>
<t:inputText id="j_username" forceId="true" value="#{backingBean.customerId}" size="40" maxlength="80"></t:inputText>
<t:inputSecret id="j_password" forceId="true" value="#{backingBean.password}" size="40" maxlength="80" redisplay="true"></t:inputSecret>
<h:commandButton action="login" value="#{messages.page_signon}"/>
<h:messages id="messages" layout="table" globalOnly="true" showSummary="true" showDetail="false"/>

A navigation rule to follow ACEGI requirements

<navigation-rule>
<from-view-id>/login.jsp</from-view-id>
<navigation-case>
<from-outcome>login</from-outcome>
<to-view-id>/j_acegi_security_check.jsp</to-view-id>
</navigation-case>
</navigation-rule>

And finaly ACEGI is told which page do the login

<bean id="formAuthenticationProcessingFilter" class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
<property name="filterProcessesUrl">
<value>/j_acegi_security_check.jsp</value>
</property>
<property name="authenticationFailureUrl">
<value>/login.faces</value>
</property>
...

[[Category:OWASP Java Project]]

Java Security Frameworks

2008-03-10T15:40:31Z

Stephendv: /* Access Control (Authentication and Authorisation) */

A list of third party (i.e. not part of Java SE or EE) security frameworks.

==Enterprise==
* [http://www.owasp.org/index.php/ESAPI OWASP Enterprise Security API] a new OWASP project to provide all essential security services under one roof.

== Access Control (Authentication and Authorisation) ==
* [http://www.acegisecurity.org/ Acegi Security] - Acegi Security is a powerful, flexible security solution for enterprise software, with a particular emphasis on applications that use Spring. Using Acegi Security provides your applications with comprehensive authentication, authorization, instance-based access control, channel security and human user detection capabilities.
* [http://sourceforge.net/projects/jguard jGuard] - jGuard is written in Java. Its goal is to provide a security framework based on JAAS (Java Authentication and Authorization Security). The framework is written for web and standalone applications, to easily provide solutions for access control problems.

== Encryption ==
* [http://www.bouncycastle.org/ Bouncycastle] - Lightweight Java cryptography APIs
* [http://www.jasypt.org/ Jasypt] - Jasypt is a java library which allows the developer to add basic encryption capabilities to his/her projects with minimum effort, and without the need of having deep knowledge on how cryptography works.

[[Category:OWASP Java Project]]

How to perform HTML entity encoding in Java

2008-01-15T12:33:34Z

Stephendv: /* Status */

==Status==
Released 14/1/2008

==Overview==

Injection attacks rely on the fact that interpreters take data and execute it as commands. If an attacker can modify the data that's sent to an interpreter, they may be able to make it misbehave. One way to help prevent this from happening is to encode the attacker's data in such a way that the interpreter will not get confused. [http://www.w3.org/TR/html401/sgml/entities.html HTML entity encoding] is just such an encoding mechanism for many interpreters.

This is not a guarantee by the way. It's almost certain that someone, probably from the XML/Web Services world, will create an engine that performs HTML entity decoding automatically, thus reintroducing the injection threat. However, for the time being, HTML entity encoding seems to work pretty well to prevent many types of injection.

==Approach==

We're going to implement a simple little method that encodes special characters. The nice .NET folks over at Microsoft had the foresight to build this into their platform, but the Java community seems to resist adding validation to the Java EE environment despite all the security issues that it could solve. View layers such as Java Server Faces, Spring-MVC, WebWork and others automatically perform HTML encoding through custom tags.

The best place for this method is in some kind of ValidationEngine, but since it's a good candidate for being static, it doesn't matter what class it ends up in that much.

Note that this implementation doesn't produce the special characters like & lt; or & gt; - but it's not difficult to implement with a simple lookup table.

public static String HTMLEntityEncode( String s )
{
StringBuffer buf = new StringBuffer();
int len = (s == null ? -1 : s.length());

for ( int i = 0; i < len; i++ )
{
char c = s.charAt( i );
if ( c>='a' && c<='z' || c>='A' && c<='Z' || c>='0' && c<='9' )
{
buf.append( c );
}
else
{
buf.append( "&#" + (int)c + ";" );
}
}
return buf.toString();
}

==Libraries==
* The Jakara Commons Lang package has a generic class for performing a wide range of [http://commons.apache.org/lang/api-release/org/apache/commons/lang/StringEscapeUtils.html String escaping functions].
* jTidy includes an [http://jtidy.sourceforge.net/multiproject/jtidyservlet/apidocs/org/w3c/tidy/servlet/util/HTMLEncode.html HTMLEncode class] for performing HTML encoding.

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

How to perform HTML entity encoding in Java

2008-01-15T12:33:15Z

Stephendv:

==Status==
Released 14/1/2008

==Overview==

Injection attacks rely on the fact that interpreters take data and execute it as commands. If an attacker can modify the data that's sent to an interpreter, they may be able to make it misbehave. One way to help prevent this from happening is to encode the attacker's data in such a way that the interpreter will not get confused. [http://www.w3.org/TR/html401/sgml/entities.html HTML entity encoding] is just such an encoding mechanism for many interpreters.

This is not a guarantee by the way. It's almost certain that someone, probably from the XML/Web Services world, will create an engine that performs HTML entity decoding automatically, thus reintroducing the injection threat. However, for the time being, HTML entity encoding seems to work pretty well to prevent many types of injection.

==Status==
Released 14/1/2007

==Approach==

We're going to implement a simple little method that encodes special characters. The nice .NET folks over at Microsoft had the foresight to build this into their platform, but the Java community seems to resist adding validation to the Java EE environment despite all the security issues that it could solve. View layers such as Java Server Faces, Spring-MVC, WebWork and others automatically perform HTML encoding through custom tags.

The best place for this method is in some kind of ValidationEngine, but since it's a good candidate for being static, it doesn't matter what class it ends up in that much.

Note that this implementation doesn't produce the special characters like & lt; or & gt; - but it's not difficult to implement with a simple lookup table.

public static String HTMLEntityEncode( String s )
{
StringBuffer buf = new StringBuffer();
int len = (s == null ? -1 : s.length());

for ( int i = 0; i < len; i++ )
{
char c = s.charAt( i );
if ( c>='a' && c<='z' || c>='A' && c<='Z' || c>='0' && c<='9' )
{
buf.append( c );
}
else
{
buf.append( "&#" + (int)c + ";" );
}
}
return buf.toString();
}

==Libraries==
* The Jakara Commons Lang package has a generic class for performing a wide range of [http://commons.apache.org/lang/api-release/org/apache/commons/lang/StringEscapeUtils.html String escaping functions].
* jTidy includes an [http://jtidy.sourceforge.net/multiproject/jtidyservlet/apidocs/org/w3c/tidy/servlet/util/HTMLEncode.html HTMLEncode class] for performing HTML encoding.

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

How to perform HTML entity encoding in Java

2008-01-15T12:32:43Z

Stephendv:

{{GAnominee|2008-01-13}}
==Status==
Released 14/1/2008

==Overview==

Injection attacks rely on the fact that interpreters take data and execute it as commands. If an attacker can modify the data that's sent to an interpreter, they may be able to make it misbehave. One way to help prevent this from happening is to encode the attacker's data in such a way that the interpreter will not get confused. [http://www.w3.org/TR/html401/sgml/entities.html HTML entity encoding] is just such an encoding mechanism for many interpreters.

This is not a guarantee by the way. It's almost certain that someone, probably from the XML/Web Services world, will create an engine that performs HTML entity decoding automatically, thus reintroducing the injection threat. However, for the time being, HTML entity encoding seems to work pretty well to prevent many types of injection.

==Status==
Released 14/1/2007

==Approach==

We're going to implement a simple little method that encodes special characters. The nice .NET folks over at Microsoft had the foresight to build this into their platform, but the Java community seems to resist adding validation to the Java EE environment despite all the security issues that it could solve. View layers such as Java Server Faces, Spring-MVC, WebWork and others automatically perform HTML encoding through custom tags.

The best place for this method is in some kind of ValidationEngine, but since it's a good candidate for being static, it doesn't matter what class it ends up in that much.

Note that this implementation doesn't produce the special characters like & lt; or & gt; - but it's not difficult to implement with a simple lookup table.

public static String HTMLEntityEncode( String s )
{
StringBuffer buf = new StringBuffer();
int len = (s == null ? -1 : s.length());

for ( int i = 0; i < len; i++ )
{
char c = s.charAt( i );
if ( c>='a' && c<='z' || c>='A' && c<='Z' || c>='0' && c<='9' )
{
buf.append( c );
}
else
{
buf.append( "&#" + (int)c + ";" );
}
}
return buf.toString();
}

==Libraries==
* The Jakara Commons Lang package has a generic class for performing a wide range of [http://commons.apache.org/lang/api-release/org/apache/commons/lang/StringEscapeUtils.html String escaping functions].
* jTidy includes an [http://jtidy.sourceforge.net/multiproject/jtidyservlet/apidocs/org/w3c/tidy/servlet/util/HTMLEncode.html HTMLEncode class] for performing HTML encoding.

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

OWASP Java Table of Contents

2008-01-15T10:59:08Z

Stephendv: /* Noteworthy Frameworks */

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]] (0% Jon Forck)
* Turbine
* [[Java Server Faces]] (Sam Reghenzi - 90%, Finalising content)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring (0%, Adrian San Juan, TD)

===[[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%)
* Bytecode verifier (0%)
* The Security Manager and security.policy file (0%)

===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, Complete)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Complete)

==== [[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, Complete)
* Prevention (100%, Stephen de Vries, Complete)

==== [[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)

''' Status '''
In progress

=== Authentication===
* [[Storing credentials]] - (20%, 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, Completed)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* [[Password length & complexity]] - (100%, 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]] (10%, 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] (100%, 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] (100%, Joe Prasanna Kumar - To be reviewed)
* [http://www.owasp.org/index.php/Digital_Signature_Implementation_in_Java Digital Signatures in Java (100%, 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, Completed)
** JSP errorPage (0%, TD)
* Web application forensics (0%, TD)

=== Web Services Security ===
* SAML (0%, TD)
* (X)WS-Security (0%, TD)
* SunJWSDP (0%, TD)
* WSS4J (0%, Eelco Klaver)
* 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, Completed)
* 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 - JChains already provides this functionality, one policy tool is enough.
* jChains (www.jchains.org) - (0%, TD)

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

==[[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

2008-01-14T17:25:25Z

Stephendv: /* 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]] (0% Needs a new owner)
* Turbine
* [[Java Server Faces]] (Sam Reghenzi - 90%, Finalising content)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring (0%, Adrian San Juan, TD)

===[[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%)
* Bytecode verifier (0%)
* The Security Manager and security.policy file (0%)

===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, Complete)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Complete)

==== [[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, Complete)
* Prevention (100%, Stephen de Vries, Complete)

==== [[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)

''' Status '''
In progress

=== Authentication===
* [[Storing credentials]] - (20%, 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, Completed)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* [[Password length & complexity]] - (100%, 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]] (10%, 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] (100%, 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] (100%, Joe Prasanna Kumar - To be reviewed)
* [http://www.owasp.org/index.php/Digital_Signature_Implementation_in_Java Digital Signatures in Java (100%, 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, Completed)
** JSP errorPage (0%, TD)
* Web application forensics (0%, TD)

=== Web Services Security ===
* SAML (0%, TD)
* (X)WS-Security (0%, TD)
* SunJWSDP (0%, TD)
* WSS4J (0%, Eelco Klaver)
* 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, Completed)
* 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 - JChains already provides this functionality, one policy tool is enough.
* jChains (www.jchains.org) - (0%, TD)

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

==[[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]]

Struts

2008-01-14T17:11:47Z

Stephendv: /* Author */

==Status==
'''Content to be finalised. First draft'''

==Introduction ==
This article describes the web security implications for the Struts MVC framework, how Struts helps in securing your web applications and where special attention is needed. It will not describe the internal details of Struts.

==Architecture==
The framework provides its own web Controller component. This Controller acts as a bridge between the application's Model and the web View. When a request is received, the Controller invokes an Action class. The Action class interacts with the Model to examine or update the application's state. The framework provides an ActionForm class to help transfer data between Model and View.

==Components==
===Action===
* No distinction is made between HTTP GET and POST method. Both methods are mapped to the same Action execute method.

===ActionForm===

===Validation===
* Integration with commons validator

==Configuration==

==Security==
===Roles===
In the struts-config.xml configuration file it is possible to specify a roles attribute, a comma-delimited list of security role names that are allowed access to the ActionMapping object.

<pre>
<action
roles="administrator,contributor"
path="/article/Edit"
parameter="org.article.FindByArticle"
name="articleForm"
scope="request">
<forward
name="success"
path="article.jsp"/>
</action>
</pre>
[[Category:OWASP Java Project]]

Using the Java Secure Socket Extensions

2008-01-14T17:11:08Z

Stephendv: /* Note */

==Status==
Requires review

''The code included in this article has not been reviewed and should not be used without proper analysis. If you have reviewed the included code (or portions of it), please post your findings back to this page or to: stephen [at] corsaire.com.''

==Overview==

===What is SSL ?===
SSL - Secure Socket Layer is an Application layer cryptographic protocol developed by Netscape for securing communication over the Internet.
The security services provided by SSL are
# Confidentiality through Encryption of data using Symmetric Key Encryption Algorithms
# Non - Repudiation of Origin / Origin Integrity through Digital Signatures using Asymmetric key Encryption Algorithms or Public Key Cryptographic Algorithms
# Data Integrity through Hashing using Message Digest or Hashing Algorithms

===What is JSSE ?===
JSSE is the acronym of Jave Secure Socket Extensions. As the name implies it is a set of Java API's which provides SSL / TLS functionalities.
JSSE follows a Provider Architecture wherein the functionalities specified in the Service Provider Interface can be implemented by any Service Provider. JSSE comes bundled with a default service provider named SunJSSE. JSSE was an optional package on jdk ##x and ##x. Since jdk ##x, JSSE comes pre-configured with the standard jdk package

===The JSSE Implementation of SSL===
JSSE provides an implementation for creating SSLSocket (used by clients) and SSLServerSocket (used by server).
====Algorithm for creating SSL Client socket====
# Determine the SSL Server Name and port in which the SSL server is listening
# Register the JSSE provider
# Create an instance of SSLSocketFactory
# Create an instance of SSLSocket
# Create an OutputStream object to write to the SSL Server
# Create an InputStream object to receive messages back from the SSL Server

====Algorithm for creating SSL Server socket====
# Register the JSSE provider
# Set System property for keystore by specifying the keystore which contains the server certificate
# Set System property for the password of the keystore which contains the server certificate
# Create an instance of SSLServerSocketFactory
# Create an instance of SSLServerSocket by specifying the port to which the SSL Server socket needs to bind with
# Initialize an object of SSLSocket
# Create InputStream object to read data sent by clients
# Create an OutputStream object to write data back to clients.

===SSL Handshake Protocol===
The SSL handshake protocol happens between the client and the server and comprises of 4 rounds that enable peers to agree on keys, ciphers and MAC algorithms. The handshake is explained below with the parameters captured in the debug mode during the execution of SSLClient and SSLServer java files.

====Round 1 : Create the SSL connection between the Client and the Server====
<pre>
C -> S {ver || randomcookie1 || sessionid || Cipher Suites || Compression Methods }
*** ClientHello, TLSv1
RandomCookie: GMT: 1165141617 bytes = { 250, 20, 142, 231, 143, 78, 72, 52, 254, 46, 199, 39, 146, 23, 238, 5, 108, 171, 75, 192, 78, 173, 26, 151, 89, 86, 58, 197 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA]
Compression Methods: { 0 }
S -> C {ver || randomcookie2 || session_id || cipher || compression }
*** ServerHello, TLSv1
RandomCookie: GMT: 1165141617 bytes = { 33, 91, 78, 189, 156, 183, 142, 253, 119, 155, 22, 193, 46, 0, 50, 153, 168, 170, 19, 220, 68, 97, 98, 3, 36, 228, 103, 117 }
Session ID: {69, 115, 166, 113, 102, 3, 65, 68, 227, 239, 225, 34, 115, 49, 73, 69, 174, 111, 222, 219, 119, 162, 5, 11, 77, 149, 181, 24, 38, 98, 5, 204}
Cipher Suite: SSL_RSA_WITH_RC4_128_MD5
Compression Method: 0
</pre>

====Round 2 : Server authenticates itself====
<pre>
S -> C {server_cert}
***
%% Created: [Session-1, SSL_RSA_WITH_RC4_128_MD5]
** SSL_RSA_WITH_RC4_128_MD5
[read] MD5 and SHA1 hashes: len = 74
0000: 02 00 00 46 03 01 45 73 A6 71 21 5B 4E BD 9C B7 ...F..Es.q![N...
0010: 8E FD 77 9B 16 C1 2E 00 32 99 A8 AA 13 DC 44 61 ..w.....#....Da
0020: 62 03 24 E4 67 75 20 45 73 A6 71 66 03 41 44 E3 b.$.gu Es.qf.AD.
0030: EF E1 22 73 31 49 45 AE 6F DE DB 77 A2 05 0B 4D .."s1IE.o..w...M
0040: 95 B5 18 26 62 05 CC 00 04 00 ...&b.....

S -> C {public key modulus || exponent || {hash (randomcookie1 || randomcookie2 || public key modulus || exponent )} signed by Server}
*** Certificate chain
chain [0] = [
[
Version: V1
Subject: CN=Jane P, OU=Network Admins, O=NewCo, L=Denver, ST=CO, C=US
Signature Algorithm: MD5withRSA, OID = ######4

Key: Sun RSA public key, 1024 bits
modulus: 125799608853960565468693082080524019040787802862173204033354805928537584240351554241990082493719007271501637788649255493925650447292814949263542483518710211756489915623917992726468465059340034326131973495929283930754477403752766287367308326998219377123365800989254595407827915805528431637337980240073881550879
public exponent: 65537
Validity: [From: Sun Nov 26 06:33:42 EST 2006,
To: Wed Apr 12 07:33:42 EDT 2034]
Issuer: CN=Jane P, OU=Network Admins, O=NewCo, L=Denver, ST=CO, C=US
SerialNumber: [ 45697b96]

]
Algorithm: [MD5withRSA]
Signature:
0000: 1A 35 AD 99 24 0A 8C 09 58 0C FC B4 B3 F8 3F DC .#.$...X.....?.
0010: 44 BF 56 A2 3A 5D E5 DF 0D CF D2 59 51 F2 6E 1C D.V.:].....YQ.n.
0020: 2A C0 03 9B 7C 3F 8B 53 C8 E9 16 A7 BC 28 23 C1 *....?.S.....(#.
0030: 67 F3 E4 05 D9 55 13 65 2E E3 80 BA A3 0A 9C F6 g....U.e........
0040: A1 50 46 90 D7 E0 8F 50 6C E4 00 5D 3F F8 D0 62 .PF....Pl..]?..b
0050: D2 A9 47 DF 65 3B 02 E8 1C 04 8A 3C 7B 19 B3 EB ..G.e;.....<....
0060: B6 50 23 6E C6 8A 49 95 6E 38 70 D2 2B 40 31 A5 .P#n..I.n8p.+@#
0070: FE 3F 44 EF 3A E4 12 69 46 D1 4F A0 83 40 F7 F3 .?D.:..iF.O..@..
]
***
S -> C { cert_type || good_cert_authorities}
S -> C {end_round_2}
</pre>
====Round 3 : Client validates the Server certificate====
<pre>
C -> S {client_cert}
C -> S {pre master secret}
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
Random Secret: { 3, 1, 161, 37, 5, 17, 154, 202, 73, 33, 75, 50, 61, 242, 44, 252, 232, 80, 161, 185, 2, 61, 154, 54, 177, 192, 141, 235, 95, 174, 219, 216, 251, 150, 189, 99, 188, 180, 15, 253, 28, 168, 85, 124, 17, 124, 218, 101 }
C -> S {hash(master secret || padding value || hash(messages || master secret || padding value))}
where messages refers to concatenation messages exchanged from 1 through #
</pre>
====Round 4 : Acknowledgment between Client and the Server====
<pre>
The client updates the session and connection information to reflect the cipher it uses and then sends a “finished” message
SESSION KEYGEN:
PreMaster Secret:
0000: 03 01 A1 25 05 11 9A CA 49 21 4B 32 3D F2 2C FC ...%....I!K2=.,.
0010: E8 50 A1 B9 02 3D 9A 36 B1 C0 8D EB 5F AE DB D8 .P...=.#..._...
0020: FB 96 BD 63 BC B4 0F FD 1C A8 55 7C 11 7C DA 65 ...c......U....e
CONNECTION KEYGEN:
Client Nonce:
0000: 45 73 A6 71 FA 14 8E E7 8F 4E 48 34 FE 2E C7 27 Es.q.....NH#..'
0010: 92 17 EE 05 6C AB 4B C0 4E AD 1A 97 59 56 3A C5 ....l.K.N...YV:.
Server Nonce:
0000: 45 73 A6 71 21 5B 4E BD 9C B7 8E FD 77 9B 16 C1 Es.q![N.....w...
0010: 2E 00 32 99 A8 AA 13 DC 44 61 62 03 24 E4 67 75 ..#....Dab.$.gu
Master Secret:
0000: B5 AF 35 36 65 B8 2E A9 F0 5C C1 A7 BD 85 98 92 ..56e....\......
0010: 64 61 B6 B9 7D 86 AB C7 72 CA 67 9A E1 C1 C4 3F da......r.g....?
0020: C5 8B 67 1A 49 C9 6E B2 FC AB 65 96 EA 7E 67 8C ..g.I.n...e...g.
Client MAC write Secret:
0000: A4 C0 36 E3 9A D3 8B 67 AA 51 D6 78 59 BF 0A 5E ..#...g.Q.xY..^
Server MAC write Secret:
0000: F7 D0 65 1D 4C 0E 81 0F 1F 76 86 D7 91 68 37 50 ..e.L....v...h7P
Client write key:
0000: A6 C5 F0 7D FE 1C 0E 58 85 00 A5 02 AE 08 B5 0E .......X........
Server write key:
0000: 20 D3 07 A2 02 02 34 67 2C C3 5A 50 7C 0F 87 CB .....4g,.ZP....
... no IV for cipher
[read] MD5 and SHA1 hashes: len = 134
0000: 10 00 00 82 00 80 10 D4 F8 1C 1D 96 62 B2 59 DD ............b.Y.
0010: D6 F8 F1 0F A5 5E 75 0F 4F 3D 5B 56 2C 6A 24 FD .....^u.O=[V,j$.
0020: 4A 90 D4 3A F3 3F 7E 22 D2 00 18 3B 7D 3F CD 02 J..:.?."...;.?..
0030: 0C E1 11 7C 12 59 D8 A3 85 8D CB 23 B7 90 1C 59 .....Y.....#...Y
0040: 94 65 5F 7E 8E 46 6D A9 7D FC 54 5D 81 DC 69 82 .e_..Fm...T]..i.
0050: 1A EE 1A A5 F1 52 66 A6 43 34 EE E0 F7 12 36 CF .....Rf.C#...#
0060: 7A 38 48 5A C9 8E 11 CB AE 7A 36 2D FD 0B CD 1A z8HZ.....z6-....
0070: 0B F1 45 1E C6 71 D9 57 39 80 75 BF D6 68 43 15 ..E..q.W#u..hC.
0080: FE 4D 67 DC 2F BD .Mg./.
[Raw read]: length = 5
0000: 14 03 01 00 01 .....
[Raw read]: length = 1
0000: 01 .
main, READ: TLSv1 Change Cipher Spec, length = 1
[Raw read]: length = 5
0000: 16 03 01 00 20 ....
[Raw read]: length = 32
0000: C7 D8 CC 69 F7 F7 7F 00 29 F6 23 C8 DD 11 50 33 ...i....).#...P3
0010: 89 BB 91 21 BD 05 24 8C 5B 77 33 9D 78 0A B4 3C ...!..$.[w#x..<
main, READ: TLSv1 Handshake, length = 32
Padded plaintext after DECRYPTION: len = 32
0000: 14 00 00 0C 01 B0 24 0D BC AD E7 E9 DC CB E4 17 ......$.........
0010: F9 FF 44 03 B2 00 37 12 9C A2 16 62 2E 9E 3C 33 ..D...#...b..<3
*** Finished
verify_data: { 1, 176, 36, 13, 188, 173, 231, 233, 220, 203, 228, 23 }

Server responds back with a “change cipher spec” message and updates its session and connection information accordingly and sends a finish message.
SESSION KEYGEN:
PreMaster Secret:
0000: 03 01 A1 25 05 11 9A CA 49 21 4B 32 3D F2 2C FC ...%....I!K2=.,.
0010: E8 50 A1 B9 02 3D 9A 36 B1 C0 8D EB 5F AE DB D8 .P...=.#..._...
0020: FB 96 BD 63 BC B4 0F FD 1C A8 55 7C 11 7C DA 65 ...c......U....e
CONNECTION KEYGEN:
Client Nonce:
0000: 45 73 A6 71 FA 14 8E E7 8F 4E 48 34 FE 2E C7 27 Es.q.....NH#..'
0010: 92 17 EE 05 6C AB 4B C0 4E AD 1A 97 59 56 3A C5 ....l.K.N...YV:.
Server Nonce:
0000: 45 73 A6 71 21 5B 4E BD 9C B7 8E FD 77 9B 16 C1 Es.q![N.....w...
0010: 2E 00 32 99 A8 AA 13 DC 44 61 62 03 24 E4 67 75 ..#....Dab.$.gu
Master Secret:
0000: B5 AF 35 36 65 B8 2E A9 F0 5C C1 A7 BD 85 98 92 ..56e....\......
0010: 64 61 B6 B9 7D 86 AB C7 72 CA 67 9A E1 C1 C4 3F da......r.g....?
0020: C5 8B 67 1A 49 C9 6E B2 FC AB 65 96 EA 7E 67 8C ..g.I.n...e...g.
Client MAC write Secret:
0000: A4 C0 36 E3 9A D3 8B 67 AA 51 D6 78 59 BF 0A 5E ..#...g.Q.xY..^
Server MAC write Secret:
0000: F7 D0 65 1D 4C 0E 81 0F 1F 76 86 D7 91 68 37 50 ..e.L....v...h7P
Client write key:
0000: A6 C5 F0 7D FE 1C 0E 58 85 00 A5 02 AE 08 B5 0E .......X........
Server write key:
0000: 20 D3 07 A2 02 02 34 67 2C C3 5A 50 7C 0F 87 CB .....4g,.ZP....
... no IV for cipher
main, WRITE: TLSv1 Change Cipher Spec, length = 1
[Raw write]: length = 6
0000: 14 03 01 00 01 01 ......
*** Finished
verify_data: { 1, 176, 36, 13, 188, 173, 231, 233, 220, 203, 228, 23 }
</pre>
Once the handshake is complete, secure communication can commence.

==The Need for Keytool==
The server needs to generate a certificate and a private key associated with its certificate. This certificate would be sent to the clients who wishes to communicate with the server. These functionalities of Key generation, Key management , certificate management are taken care by a tool provided by Sun known as keytool. Keytool uses keystores to store the public / private keys as well as certificates.
keystores are datastores implemented as files. Private keys are protected with passwords.

===Algorithms supported by Keytool===
Keytool supports any algorithm implemented by the registered cryptographic service providers. Default key pair generation algorithm is DSA with a keysize of 1024 bits. The signature algorithm is derived from the algorithm of the private keys. DSA gets coupled with SHA1 by default and so "SHA1withDSA" would be used. RSA gets coupled with MD5 and so "MD5withRSA" would be used.

===Some of the frequently used functions of keytool are:===
==== Generating keys using keytools====
Key pairs can be generated using keytool with the following command and options
<pre>
$bash # keytool -genkey -alias testkey -keystore testkeystore.ks
Enter keystore password: testpwd
What is your first and last name?
[Unknown]: Tom
What is the name of your organizational unit?
[Unknown]: security
What is the name of your organization?
[Unknown]: ABC Inc
What is the name of your City or Locality?
[Unknown]: Fort Meade
What is the name of your State or Province?
[Unknown]: MA
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=Tom, OU=security, O=ABC Inc, L=Fort Meade, ST=MA, C=US correct?
[no]: y

Enter key password for <testkey>
(RETURN if same as keystore password):
</pre>
* The option ''-genkey'' is used to generate the keys.
* ''-alias'' specifies the name of the key. This can be verified by the command keytool -list -keystore testkeystore.ks
* ''-keystore'' is the name of the keystore to where the key needs to be added. If no keystore name is specified, the generated keys will be added to the default keystore. The default keystore gets autogenerated when the first key is created and is located in the users home directory with an ".keystore" extension. 

The following defaults would be applied during the genkey process:
* keyalg - defaults to DSA
* keysize - defaults to 1024 bits
* validity - defaults to 90 days

====Importing certificates into keystore from .cer files====
A certificate represented usually by a .cer file is imported into the keystore so that it gets added to the list of trusted certificates.
<pre>
$bash # keytool -import -keystore testkeystore.ks -file ssltest.cer
Enter keystore password: testpwd
Owner: CN=Jane P, OU=Network Admins, O=NewCo, L=Denver, ST=CO, C=US
Issuer: CN=Jane P, OU=Network Admins, O=NewCo, L=Denver, ST=CO, C=US
Serial number: 45697b96
Valid from: Sun Nov 26 06:33:42 EST 2006 until: Wed Apr 12 07:33:42 EDT 2034
Certificate fingerprints:
MD5: BD:AA:A5:77:AC:92:17:0E:D3:6E:E2:8F:2B:12:A5:6C
SHA1: 2F:BF:88:E1:2F:26:B9:C3:64:5E:C5:7F:F4:BF:43:7F:37:3D:BE:C5
Trust this certificate? [no]: yes
Certificate was added to keystore
</pre>
The certificate ssltest.cer is successfully imported into the keystore. The serial number generated is unique to this certificate and is useful during certificate revocations. When a certificate is revoked, the serial number gets added to the CRL (Certificate revocation list).
'''Warning:'''
'''Before importing a certificate, validate if the certificate really belongs to the entity it claims to represent.'''
====Use the keytool -printcert -file ssltest.cer to view the contents of the certificate====
<pre>
$bash # keytool -printcert -file ssltest.cer
Owner: CN=Jane P, OU=Network Admins, O=NewCo, L=Denver, ST=CO, C=US
Issuer: CN=Jane P, OU=Network Admins, O=NewCo, L=Denver, ST=CO, C=US
Serial number: 45697b96
Valid from: Sun Nov 26 06:33:42 EST 2006 until: Wed Apr 12 07:33:42 EDT 2034
Certificate fingerprints:
MD5: BD:AA:A5:77:AC:92:17:0E:D3:6E:E2:8F:2B:12:A5:6C
SHA1: 2F:BF:88:E1:2F:26:B9:C3:64:5E:C5:7F:F4:BF:43:7F:37:3D:BE:C5

# Verify from the Issuer of the certificate if the Certificate fingerprint matches.
</pre>

==== Exporting certificates from keystore to files====
To export a certificate from a keystore to a file, the following command could be used
<pre>
$bash # keytool -export -alias testkey -keystore testkeystore.ks -file testkey.cer
Enter keystore password: testpwd
Certificate stored in file <testkey.cer>
Now you can verify the contents of the exported certificate using the command.
$bash # keytool -printcert -file testkey.cer
Owner: CN=Tom, OU=security, O=ABC Inc, L=Fort Meade, ST=MA, C=US
Issuer: CN=Tom, OU=security, O=ABC Inc, L=Fort Meade, ST=MA, C=US
Serial number: 45736152
Valid from: Sun Dec 03 18:44:18 EST 2006 until: Sat Mar 03 18:44:18 EST 2007
Certificate fingerprints:
MD5: 8F:D3:EA:E7:B0:CF:9C:03:16:2F:3F:C9:6C:BC:5A:D4
SHA1: 03:2B:C6:BD:D9:82:31:08:F1:88:3C:35:AD:8D:F9:C3:90:5E:53:6F
</pre>
==Examples==
===SSLClient.java===
<pre>
package org.owasp.crypto;

import java.io.*;

import javax.net.ssl.*;
import com.sun.net.ssl.*;
import com.sun.net.ssl.internal.ssl.Provider;
import java.security.Security;

/**
* @author Joe Prasanna Kumar
* This program simulates a client socket program which communicates with the SSL Server
*
* Algorithm:
* 1. Determine the SSL Server Name and port in which the SSL server is listening
* 2. Register the JSSE provider
* 3. Create an instance of SSLSocketFactory
* 4. Create an instance of SSLSocket
* 5. Create an OutputStream object to write to the SSL Server
* 6. Create an InputStream object to receive messages back from the SSL Server
*
*/

public class SSLClient {

/**
* @param args
*/
public static void main(String[] args) throws Exception{
String strServerName = "localhost"; // SSL Server Name
int intSSLport = 4443; // Port where the SSL Server is listening
PrintWriter out = null;
BufferedReader in = null;

{
// Registering the JSSE provider
Security.addProvider(new Provider());
}

try {
// Creating Client Sockets
SSLSocketFactory sslsocketfactory = (SSLSocketFactory)SSLSocketFactory.getDefault();
SSLSocket sslSocket = (SSLSocket)sslsocketfactory.createSocket(strServerName,intSSLport);

// Initializing the streams for Communication with the Server
out = new PrintWriter(sslSocket.getOutputStream(), true);
in = new BufferedReader(new InputStreamReader(sslSocket.getInputStream()));

BufferedReader stdIn = new BufferedReader(new InputStreamReader(System.in));
String userInput = "Hello Testing ";
out.println(userInput);

while ((userInput = stdIn.readLine()) != null) {
out.println(userInput);
System.out.println("echo: " + in.readLine());
}

out.println(userInput);

// Closing the Streams and the Socket
out.close();
in.close();
stdIn.close();
sslSocket.close();
}

catch(Exception exp)
{
System.out.println(" Exception occured .... " +exp);
exp.printStackTrace();
}

}

}
</pre>

===SSLServer.java===
<pre>
package org.owasp.crypto;

import java.io.*;
import java.security.Security;
import java.security.PrivilegedActionException;

import javax.net.ssl.*;
import com.sun.net.ssl.*;
import com.sun.net.ssl.internal.ssl.Provider;

/**
* @author Joe Prasanna Kumar
* This program simulates an SSL Server listening on a specific port for client requests
*
* Algorithm:
* 1. Regsiter the JSSE provider
* 2. Set System property for keystore by specifying the keystore which contains the server certificate
* 3. Set System property for the password of the keystore which contains the server certificate
* 4. Create an instance of SSLServerSocketFactory
* 5. Create an instance of SSLServerSocket by specifying the port to which the SSL Server socket needs to bind with
* 6. Initialize an object of SSLSocket
* 7. Create InputStream object to read data sent by clients
* 8. Create an OutputStream object to write data back to clients.
*
*/

public class SSLServer {

/**
* @param args
*/

public static void main(String[] args) throws Exception{

int intSSLport = 4443; // Port where the SSL Server needs to listen for new requests from the client

{
// Registering the JSSE provider
Security.addProvider(new Provider());

//Specifying the Keystore details
System.setProperty("javax.net.ssl.keyStore","server.ks");
System.setProperty("javax.net.ssl.keyStorePassword","JsEkey@4");

// Enable debugging to view the handshake and communication which happens between the SSLClient and the SSLServer
// System.setProperty("javax.net.debug","all");
}

try {
// Initialize the Server Socket
SSLServerSocketFactory sslServerSocketfactory = (SSLServerSocketFactory)SSLServerSocketFactory.getDefault();
SSLServerSocket sslServerSocket = (SSLServerSocket)sslServerSocketfactory.createServerSocket(intSSLport);
SSLSocket sslSocket = (SSLSocket)sslServerSocket.accept();

// Create Input / Output Streams for communication with the client
while(true)
{
PrintWriter out = new PrintWriter(sslSocket.getOutputStream(), true);
BufferedReader in = new BufferedReader(
new InputStreamReader(
sslSocket.getInputStream()));
String inputLine, outputLine;

while ((inputLine = in.readLine()) != null) {
out.println(inputLine);
System.out.println(inputLine);
}

// Close the streams and the socket
out.close();
in.close();
sslSocket.close();
sslServerSocket.close();

}
}

catch(Exception exp)
{
PrivilegedActionException priexp = new PrivilegedActionException(exp);
System.out.println(" Priv exp --- " + priexp.getMessage());

System.out.println(" Exception occured .... " +exp);
exp.printStackTrace();
}

}

}

</pre>

==References==
* Computer Security – Arts and Science - Matt Bishop
* Core Security Patterns – Christopher Steele, Ray Lai and Ramesh Nagappan
* http://java.sun.com/j2se/##2/docs/tooldocs/windows/keytool.html
* http://blogs.borland.com/krish/archive/2005/07/28/#aspx

[[Category:OWASP Java Project]]

Talk:Securing tomcat

2008-01-14T16:58:03Z

Stephendv:

What's the best way to acknowledge the contributions of others as I'd like to add some thanks to Kris Easter, Michel Prunet and Stephen More. This discussion area? In brackets after the article link from [https://www.owasp.org/index.php/OWASP_Java_Project_Roadmap#Securing_Popular_J2EE_Servers Java Project Roadmap] ? [[User:Dledmonds|Darren]] 08:58, 27 October 2006 (EDT)

I've added an acknowledgements section to the main page. [[User:Stephendv|Stephendv]] 11:58, 14 January 2008 (EST)

==UNIX Permissions==

> Change files in CATALINA_HOME/conf to be readonly (440)

Initially these are 600 (except for tomcat-users.xml which is 644 and Tomcat keeps it that way). Is there a need to make them group-readable?

> Make sure tomcat user has ... write (220 - yes, only write) access to CATALINA_HOME/logs

This doesn't work. I think the best that can be done here is 750 or 700.

[[User:Combatopera|Combatopera]] 15:53, 12 November 2006 (EST)

CATALINA_HOME/conf files updated to recommend chmod 400. tomcat-user.xml the same as tomcat doesn't write to it. Original file permissions for all these conf files were 600 when 5.5.20 was unpacked on a debian box.

CATALINA_HOME/logs directory updated to recommend chmod 300. Prevents tomcat user reading the logs within, but writing works fine for me - again after 5.5.20 was unpacked on a debian box.

[[User:Dledmonds|Darren]] 04:35, 9 January 2007 (EST)

Securing tomcat

2008-01-14T16:57:02Z

Stephendv:

==Status==
Released 14/1/2007

== Introduction ==

Most weaknesses in [http://tomcat.apache.org/ Apache Tomcat] come from incorrect or inappropriate configuration. It is nearly always possible to make Tomcat more secure than the default out of the box installation. What follows documents best practices and recommendations on securing a production Tomcat server, whether it be hosted on a Windows or Unix based operating system. ''Please note that the section ordering is not a representation of the section importance.''

== Software Versions ==

The first step is to make sure you are running the latest stable releases of software;
* Java Runtime Environment (JRE) or SDK
* Tomcat
* Third party libraries
This does not mean you have to upgrade all your production servers to a new (and potentially buggy) release which has just been made available to the public. What you must do is download the latest stable bugfix release that has continual support. For the JRE and Tomcat you should be looking at the last digits in the version number (5.5.'''X''') as it represents the bugfix information. The bugs fixed in these releases are publicly available so if you don't upgrade you could be providing attackers with a very easy route to compromise your server.

== Installation of Apache Tomcat 5.5 ==

=== UNIX ===

* Create a tomcat user/group
* Download and unpack the core distribution (referenced as '''CATALINA_HOME''' from now on)
* Change '''CATALINA_HOME''' ownership to tomcat user and tomcat group
* Change files in '''CATALINA_HOME'''/conf to be readonly (400)
* Make sure tomcat user has read/write access to /tmp and write (300 - yes, only write/execute) access to '''CATALINA_HOME'''/logs

=== Windows ===

* Download the core windows service installer
* Start the installation, click ''Next'' and ''Agree'' to the licence
* Untick ''native'', ''documentation'', ''examples'' and ''webapps'' then click ''Next''
* Choose an installation directory (referenced as '''CATALINA_HOME''' from now on), preferably on a different drive to the OS.
* Choose an administrator username (NOT admin) and a secure password that complies with your organisations password policy.
* Complete tomcat installation, but do not start service.

=== Common ===

* Remove everything from '''CATALINA_HOME'''/webapps (ROOT, balancer, jsp-examples, servlet-examples, tomcat-docs, webdav)

* Remove everything from '''CATALINA_HOME'''/server/webapps (host-manager, manager). Note that it can be useful to keep the manager webapp installed if you need the ability to redeploy without restarting Tomcat. If you choose to keep it please read the section on Securing the Manager WebApp.

* Remove '''CATALINA_HOME'''/conf/Catalina/localhost/host-manager.xml and '''CATALINA_HOME'''/conf/Catalina/localhost/manager.xml (again, if you are keeping the manager application, do not remove this).

* Make sure the default servlet is configured '''not''' to serve index pages when a welcome file is not present. In '''CATALINA_HOME'''/conf/web.xml
<servlet>
<servlet-name>default</servlet-name>
<servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>listings</param-name>
<param-value>'''false'''</param-value> 
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>

* Remove version string from HTTP error messages by repacking '''CATALINA_HOME'''/server/lib/catalina.jar with an updated ServerInfo.properties file. Note that making this change may prevent [http://www.lambdaprobe.org Lambda Probe] (popular Tomcat monitoring webapp) to initialise as it cannot determine the Tomcat version. A solution to this can be found on the [http://www.lambdaprobe.org/forum2/message.jspa?messageID=477 Lambda Probe Forum].
:unpack catalina.jar
cd CATALINA_HOME/server/lib
jar xf catalina.jar org/apache/catalina/util/ServerInfo.properties
:update ServerInfo.properties by changing server.info line to server.info=Apache Tomcat
:repackage catalina.jar
jar uf catalina.jar org/apache/catalina/util/ServerInfo.properties
:remove CATALINA_HOME/server/lib/org (created when extracting the ServerInfo.properties file)

* Replace default error page (default is stacktrace) by adding the following into '''CATALINA_HOME'''/conf/web.xml. The default error page shows a full stacktrace which is a disclosure of sensitive information. Place the following within the ''web-app'' tag (after the ''welcome-file-list'' tag is fine). ''The following solution is not ideal as it produces a blank page because Tomcat cannot find the file specified, but without a better solution this, at least, achieves the desired result. A well configured web application will override this default in CATALINA_HOME/webapps/APP_NAME/WEB-INF/web.xml so it won't cause problems.''
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
* Rename '''CATALINA_HOME'''/conf/server.xml to '''CATALINA_HOME'''/conf/server-original.xml and rename '''CATALINA_HOME'''/conf/server-minimal.xml to '''CATALINA_HOME'''/conf/server.xml. The minimal configuration provides the same basic configuration, but without the nested comments is much easier to maintain and understand. Do not delete the original file as the comments make it useful for reference if you ever need to make changes - e.g. enable SSL.

* Replace the server version string from HTTP headers in server responses, by adding the server keyword in your Connectors in '''CATALINA_HOME'''/conf/server.xml
<Connector port="8080" ...
server="Apache" /> 

* Start Tomcat, deploy your applications into '''CATALINA_HOME'''/webapps and hope it works!

== Protecting the Shutdown Port ==
Tomcat uses a port (defaults to 8005) as a shutdown port. What this means is that to stop all webapps and stop Tomcat cleanly the shutdown scripts make a connection to this port and send the ''shutdown'' command. This is not as huge a security problem as it may sound considering the connection to the port must be made from the machine running tomcat and the ''shutdown'' command can be changed to something other than the string ''SHUTDOWN''. However, it's wise to take the following precautions;
* if you are running a publicly accessible server make sure you prevent external access to the shutdown port by using a suitable firewall.
* change the shutdown command in '''CATALINA_HOME'''/conf/server.xml and make sure that file is only readable by the tomcat user.
<Server port="8005" shutdown="ReallyComplexWord">
* if this is still a big problem for you then check [http://marc.theaimsgroup.com/?l=tomcat-user&m=104400608619118&w=2 this thread], from the Tomcat mailing list, for alternatives (they all involve code customisation though).

== Securing Manager WebApp ==

* By default there are no users with the manager role. To make use of the manager webapp you need to add a new role and user into the '''CATALINA_HOME'''/conf/tomcat-users.xml file.
<role rolename="manager"/>
<user username="darren" password="ReallyComplexPassword" roles="manager"/>

* Using a [http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html valve] to filter by IP or hostname to only allow a subset of machines to connect (i.e. LAN machines). Add one of the following within the Context tag in '''CATALINA_HOME'''/conf/Catalina/localhost/manager.xml



<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="192.168.1.*" />




<Valve className="org.apache.catalina.valves.RemoteHostValve"
allow="*.localdomain.com" />

* You can rename the manager webapp to something else, e.g. ''foobar''
** Move '''CATALINA_HOME'''/conf/Catalina/localhost/'''manager.xml''' to '''CATALINA_HOME'''/conf/Catalina/localhost/'''foobar.xml'''
** Update the '''docBase''' attribute within '''CATALINA_HOME'''/conf/Catalina/localhost/'''foobar.xml''' to ${catalina.home}/server/webapps/foobar
** Move '''CATALINA_HOME'''/server/webapps/'''manager''' to '''CATALINA_HOME'''/server/webapps/'''foobar'''

== Logging ==

As of tomcat 5.5 logging is now handled by the commons-logging framework allowing you to choose your preferred logging implementation - log4j or standard JDK logging. By default the standard JDK logging is used (or a compatible extension called juli to be more precise), storing daily log files in '''CATALINA_HOME'''/logs.

By default additional webapp log entries are added to '''CATALINA_HOME'''/logs/catalina.YYYY-MM-DD.log and System.out/System.err are redirected to '''CATALINA_HOME'''/logs/catalina.out. To place webapp log entries in individual log files create a ''logging.properties'' file similar to the following within '''CATALINA_HOME'''/webapps/''APP_NAME''/WEB-INF/classes (change the ''APP_NAME'' value to create a unique file for each webapp)

handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
org.apache.juli.FileHandler.level = ALL
org.apache.juli.FileHandler.directory = ${catalina.base}/logs
org.apache.juli.FileHandler.prefix = APP_NAME.

Further details on logging configuration can be found in the [http://tomcat.apache.org/tomcat-5.5-doc/logging.html tomcat logging documentation.]

If you find you get logging output duplicated in catalina.out, you most likely have unnecessary entries for ''java.util.logging.ConsoleHandler'' in your logging configuration file.

== Encryption ==

* SSL for password or other sensitive data exchange (''bordering on application security, not specific to tomcat'')
* SSL for connections (JDBC, LDAP, etc ..)
* The Tomcat documentation clearly explains how to [http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html enable SSL.]

== Java Security ==

=== Running Tomcat with a Security Manager===
The default Tomcat configuration provides good protection for most requirements, but does not prevent a malicious application from compromising the security of other applications running in the same instance. To prevent this sort of attack, Tomcat can be run with a Security Manager enabled which strictly controls access to server resources.
Tomcat documentation has a good section on [http://tomcat.apache.org/tomcat-5.5-doc/security-manager-howto.html enabling the Security Manager.]

== Miscellaneous ==

* [http://tomcat.apache.org/faq/security.html Tomcat Security FAQ]

=== Using Port 80 ===

If you are on a Windows machine you will be able to change the port attribute of the connector within the ''Catalina'' service from 8080 to 80. This allows you to use tomcat directly to serve all requests. Depending on your requirements it may not be good enough to serve directly from Tomcat so you may like to consider;
* Use IIS / Apache running on port 80 and mod_jk to proxy requests to Tomcat

On a UNIX machine only root is allowed to run services on ports below 1024 (kernel recompilation can overcome this). It is a very bad idea to run Tomcat as root, so the options are (in no particular order);
* Use Apache running on port 80 and mod_jk (or mod_proxy_ajp) to proxy requests to Tomcat
* Run Tomcat as root, but in a chroot jail
* Use a tool like authbind to enable a non root user to bind to ports below 1024
* Use a port forwarder such as [http://www.netfilter.org/projects/iptables/index.html Iptables] to redirect incoming requests from 8080 to 80. This has the disadvantage that internal redirects still need to use 8080.
* Run [http://www.squid-cache.org/ Squid] as a web accelerator in front of Tomcat
* Use JSVC/procrun
Each of the above options '''may''' bring extra security concerns which are outside the scope of this document.

=== Cleartext Passwords in CATALINA_HOME/conf/server.xml ===

When configuring a resource, such as a JDBC pool, it is necessary to include clear text username and password in CATALINA_HOME/conf/server.xml Best practices advice us never to store clear text passwords, but the following paragraphs highlight it is very difficult to avoid.

If one way encryption was used on the password it must be possible for a database connection to be established using a username and encrypted password - so the encrypted password is just as valuable as the clear text one to an attacker.

If two way encryption was used a keyfile is needed which must also live on the filesystem. To make it more secure a passphase is added to the keyfile which then has to be stored in the configuration as clear text - no improvement.

Encoding is security by obscurity and offers no form of protection (algorithms can be reverse engineered). What encoding does do is make huge amounts of overhead work - you need to customise Tomcat and the commons digester it uses to parse the config files. You'd also need a way to create encoded passwords.

In the case of a JDBC pool what you can do is;
* make sure the database user only has access to the databases and tables they need (also limit rights as necessary).
* make sure the raw database files are only accessible to the user running the database services (e.g. mysql/postgresql user)
* make sure the Tomcat configuration files are only accessible to the tomcat user

==Acknowledgements==
The author would like to thank Kris Easter, Michel Prunet and Stephen More for their valuable input.

[[Category:OWASP Java Project]]
[[Category:Java]]

SSL Best Practices

2008-01-14T16:52:12Z

Stephendv: /* Status */

== Status ==
Draft

==What is SSL==

SSL is the abbreviation of Secured Socket Layer. It is a protocol enabling to settle a secured communication between two hosts. The origin host is viewed as an SSL client and the destination host as an SSL server.

SSL has also been normalised as the TLS (Transport Layer Security) protocol.

'''SSL is used on top of a transport level protocol''' like HTTP or FTP in order to secure it.

SSL enables :
* authentication of the destination host for the origin host or mutual authentication of both the origin and the destination hosts
* data confidentiality through encryption
* data integrity checking through hashing.

SSL relies on two types of encryption :
* public key encryption in the initiation phase, where authentication takes place
* secret key encryption when a session has been established and data is sent between two peers which trust each other.

'''SSL only secures the communication between two endpoints''' : in the origin and destination points, data is in clear text, unless it is encrypted by another means, at the application level.

==How SSL is implemented in J2EE==
==HTTPS best practices in general==
==HTTPS best practices in J2EE==
==Examples with Tomcat==
==Examples with JBoss==

[[Category:OWASP Java Project]]

Talk:Protecting code archives with digital signatures

2008-01-14T16:50:30Z

Stephendv:

==Status==
Reviewed [[User:Stephendv|Stephendv]] 11:50, 14 January 2008 (EST)

==Authors==
* Pierre Parrend

==Reviewers==
* Stephen de Vries

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

Preventing SQL Injection in Java

2008-01-14T16:35:43Z

Stephendv:

==Status==
Released 14/1/2008

==Overview==
As the name implies, SQL injection vulnerabilities allow an attacker to inject (or execute) SQL commands within an application. It is one of the most wide spread and dangerous application vulnerability. The CLASP project provides a good overview of [[SQL injection]].
===Example of SQL injection===
The following Java servlet code, used to perform a login function, illustrates the vulnerability by accepting user input without performing adequate input validation or escaping meta-characters:
conn = pool.getConnection( );
String sql = "select * from user where username='" + username +"' and password='" + password + "'";
stmt = conn.createStatement();
rs = stmt.executeQuery(sql);
if (rs.next()) {
loggedIn = true;
out.println("Successfully logged in");
} else {
out.println("Username and/or password not recognized");
}
It is possible for attackers to provide a username containing SQL meta-characters that subvert the intended function of the SQL statement. For example, by providing a username of:
admin' OR '1'='1
and a blank password, the generated SQL statement becomes:
select * from user where username='admin' OR '1'='1' and password=' '
This allows an attacker to log in to the site without supplying a password, since the ‘OR’ expression is always true. Using the same technique attackers can inject other SQL commands which could extract, modify or delete data within the database.
===Attack techniques===
For more information on SQL injection attacks see:
* http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
* http://www.nextgenss.com/papers/advanced_sql_injection.pdf
* http://www.appsecinc.com/presentations/Manipulating_SQL_Server_Using_SQL_Injection.pdf
==Defence Strategy==
To prevent SQL injection, a two pronged approach is recommended:
* Firstly, all data accepted from user input should be thoroughly validated to ensure that the characters received are part of the set of valid characters for that field;
* Secondly, all data acted on by SQL commands should be escaped for meta-characters.
=== Validating Input ===
A general security principle which applies itself well to data validation is that of “deny by default” where data is rejected unless it specifically matches the criteria for known good data. This is also known as a “white list” approach and is the preferred method for performing data validation. It allows one to define a restricted range for valid data and reject everything that does not fit this set. The set of valid data should be constrained by:
* Type – String, integer, unsigned integer, float etc;
* Length;
* Set of character – for example, only alphabetic characters [a-zA-Z]*;
* Format – if appropriate the data could be further constrained by specifying a format, e.g.: \d\d\/\d\d\/\d\d
* Reasonableness – where possible, values should be compared to expected ranges. For example, a customer ordering 1000 televisions could be suspicious.
It is essential that the data validation routines themselves can be trusted, therefore they must be performed on the server side. Client side validation can be performed as a useful user interface feature, but it must be reinforced by server side validation.
Where input validation is performed on the server side will depend largely on the frameworks available. JSF and Struts provide validation functions that are defined in the view layer, while Spring and EJB 3.0 allow validation to be defined in the model. 
Input validation provides the first line of defence in preventing dangerous characters from being processed by the application.
But even if data is constrained in this way it does not solve the meta-character problem: How should the application handle meta-characters that are defined as valid data, but cannot be used in certain processing contexts? For example, the single quote (') character may be a valid character in a surname, but this character cannot simply be used in a string that is used to form an SQL statement. The OWASP Guide project has more information on [[Data Validation]].
=== Escaping Meta-characters ===
All data access techniques provide some means for escaping SQL meta-characters automatically. The important thing to remember is to never construct SQL statements using string concatenation of unchecked input values. The following sections detail how to perform input validation and meta-character escaping using popular data access technologies.
==Prepared Statements==
Variables passed as arguments to prepared statements will automatically be escaped by the JDBC driver. 
Example: ps.1 
String selectStatement = "SELECT * FROM User WHERE userId = ? ";
PreparedStatement prepStmt = con.prepareStatement(selectStatement);
prepStmt.setString(1, userId);
ResultSet rs = prepStmt.executeQuery();

Although Prepared Statements helps in defending against SQL Injection, there are possibilities of SQL Injection attacks through inappropriate usage of Prepared Statements. The example below explains such a scenario where the input variables are passed directly into the Prepared Statement and thereby paving way for SQL Injection attacks. 
Example: ps.2 
<pre>
String strUserName = request.getParameter("Txt_UserName");
PreparedStatement prepStmt = con.prepareStatement("SELECT * FROM user WHERE userId = '+strUserName+'");
</pre>
It is highly recommended to use Bind Variables as mentioned in the example ps.1 above. Usage of PreparedStatement with Bind variables defends SQL Injection attacks and improves the performance.

==Stored Procedures==
==Hibernate==
According to [http://forum.hibernate.org/viewtopic.php?t=960817&start=0&postdays=0&postorder=asc this forum thread] hibernate uses prepared statements, so it is protected from direct sql injection, but it could still be vulnerable to [http://www.owasp.org/index.php/Interpreter_Injection#ORM_Injection injecting HQL statements].

==Ibatis==

Ibatis creates prepared statements for database access.
However, SQL injection is possible in Ibatis if the $$ variable replacement syntax is used. 

Vulnerable: 
<select id=“vuln" resultMap=“myResultMap”> select * from table where id = $value$</select>

The above query is called as follows:
MyBean b = (MyBean)sqlMap.queryForObject("vuln", new Integer(1));

The SQL statement thus created, looks as follows:

select * from table where id = 1

The object passed as parameter is directly fed to the SQL query making it susceptible to SQL injection 

 Secure: 

<select id=“vuln" resultMap=“myResultMap”> select * from table where id = #value#</select>

Using this form instead generates the following SQL

select * from table where id = ?

The value of the parameter is sent directly to the driver and not used to modify the SQL statement itself. 
This approach thwarts SQL injection attacks by automatically escaping SQL meta-characters.

== References ==
*[1] [http://research.corsaire.com/whitepapers/060116-a-modular-approach-to-data-validation.pdf A Modular Approach to Data Validation]
*[2] [http://forum.hibernate.org/viewtopic.php?t=960817&start=0&postdays=0&postorder=asc&highlight= Topic: does Hibernate guard against SQL injection?]

[[Category:OWASP Java Project]]

Preventing SQL Injection in Java

2008-01-14T16:34:47Z

Stephendv:

==Status==
Released 14/1/2008

==Overview==
As the name implies, SQL injection vulnerabilities allow an attacker to inject (or execute) SQL commands within an application. It is one of the most wide spread and dangerous application vulnerability. The CLASP project provides a good overview of [[SQL injection]].
===Example of SQL injection===
The following Java servlet code, used to perform a login function, illustrates the vulnerability by accepting user input without performing adequate input validation or escaping meta-characters:
conn = pool.getConnection( );
String sql = "select * from user where username='" + username +"' and password='" + password + "'";
stmt = conn.createStatement();
rs = stmt.executeQuery(sql);
if (rs.next()) {
loggedIn = true;
out.println("Successfully logged in");
} else {
out.println("Username and/or password not recognized");
}
It is possible for attackers to provide a username containing SQL meta-characters that subvert the intended function of the SQL statement. For example, by providing a username of:
admin' OR '1'='1
and a blank password, the generated SQL statement becomes:
select * from user where username='admin' OR '1'='1' and password=' '
This allows an attacker to log in to the site without supplying a password, since the ‘OR’ expression is always true. Using the same technique attackers can inject other SQL commands which could extract, modify or delete data within the database.
===Attack techniques===
For more information on SQL injection attacks see:
* http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
* http://www.nextgenss.com/papers/advanced_sql_injection.pdf
* http://www.appsecinc.com/presentations/Manipulating_SQL_Server_Using_SQL_Injection.pdf
==Defence Strategy==
To prevent SQL injection, a two pronged approach is recommended:
* Firstly, all data accepted from user input should be thoroughly validated to ensure that the characters received are part of the set of valid characters for that field;
* Secondly, all data acted on by SQL commands should be escaped for meta-characters.
=== Validating Input ===
A general security principle which applies itself well to data validation is that of “deny by default” where data is rejected unless it specifically matches the criteria for known good data. This is also known as a “white list” approach and is the preferred method for performing data validation. It allows one to define a restricted range for valid data and reject everything that does not fit this set. The set of valid data should be constrained by:
* Type – String, integer, unsigned integer, float etc;
* Length;
* Set of character – for example, only alphabetic characters [a-zA-Z]*;
* Format – if appropriate the data could be further constrained by specifying a format, e.g.: \d\d\/\d\d\/\d\d
* Reasonableness – where possible, values should be compared to expected ranges. For example, a customer ordering 1000 televisions could be suspicious.
It is essential that the data validation routines themselves can be trusted, therefore they must be performed on the server side. Client side validation can be performed as a useful user interface feature, but it must be reinforced by server side validation.
Where input validation is performed on the server side will depend largely on the frameworks available. JSF and Struts provide validation functions that are defined in the view layer, while Spring and EJB 3.0 allow validation to be defined in the model. 
Input validation provides the first line of defence in preventing dangerous characters from being processed by the application.
But even if data is constrained in this way it does not solve the meta-character problem: How should the application handle meta-characters that are defined as valid data, but cannot be used in certain processing contexts? For example, the single quote (') character may be a valid character in a surname, but this character cannot simply be used in a string that is used to form an SQL statement. The OWASP Guide project has more information on [[Data Validation]].
=== Escaping Meta-characters ===
All data access techniques provide some means for escaping SQL meta-characters automatically. The important thing to remember is to never construct SQL statements using string concatenation of unchecked input values. The following sections detail how to perform input validation and meta-character escaping using popular data access technologies.
==Prepared Statements==
Variables passed as arguments to prepared statements will automatically be escaped by the JDBC driver. 
Example: ps.1 
String selectStatement = "SELECT * FROM User WHERE userId = ? ";
PreparedStatement prepStmt = con.prepareStatement(selectStatement);
prepStmt.setString(1, userId);
ResultSet rs = prepStmt.executeQuery();

Although Prepared Statements helps in defending against SQL Injection, there are possibilities of SQL Injection attacks through inappropriate usage of Prepared Statements. The example below explains such a scenario where the input variables are passed directly into the Prepared Statement and thereby paving way for SQL Injection attacks. 
Example: ps.2 
<pre>
String strUserName = request.getParameter("Txt_UserName");
PreparedStatement prepStmt = con.prepareStatement("SELECT * FROM user WHERE userId = '+strUserName+'");
</pre>
It is highly recommended to use Bind Variables as mentioned in the example ps.1 above. Usage of PreparedStatement with Bind variables defends SQL Injection attacks and improves the performance.

==Stored Procedures==
==Hibernate==
According to [http://forum.hibernate.org/viewtopic.php?t=960817&start=0&postdays=0&postorder=asc this forum thread] hibernate uses prepared statements, so it is protected from direct sql injection, but it could still be vulnerable to [http://www.owasp.org/index.php/Interpreter_Injection#ORM_Injection injecting HQL statements].

==Ibatis==

Ibatis creates prepared statements for database access.
However, SQL injection is possible in Ibatis if the $$ variable replacement syntax is used. 

Vulnerable: 
<select id=“vuln" resultMap=“myResultMap”> select * from table where id = $value$</select>

The above query is called as follows:
MyBean b = (MyBean)sqlMap.queryForObject("vuln", new Integer(1));

The SQL statement thus created, looks as follows:

select * from table where id = 1

The object passed as parameter is directly fed to the SQL query making it susceptible to SQL injection 

 Secure: 

<select id=“vuln" resultMap=“myResultMap”> select * from table where id = #value#</select>

Using this form instead generates the following SQL

select * from table where id = ?

The value of the parameter is sent directly to the driver and not used to modify the SQL statement itself. 
This approach thwarts SQL injection attacks by automatically escaping SQL meta-characters.

==Spring JDBC==
==EJB 3.0==

== References ==
*[1] [http://research.corsaire.com/whitepapers/060116-a-modular-approach-to-data-validation.pdf A Modular Approach to Data Validation]
*[2] [http://forum.hibernate.org/viewtopic.php?t=960817&start=0&postdays=0&postorder=asc&highlight= Topic: does Hibernate guard against SQL injection?]

[[Category:OWASP Java Project]]

Preventing SQL Injection in Java

2008-01-14T16:28:30Z

Stephendv: /* Hibernate */

==Overview==
As the name implies, SQL injection vulnerabilities allow an attacker to inject (or execute) SQL commands within an application. It is one of the most wide spread and dangerous application vulnerability. The CLASP project provides a good overview of [[SQL injection]].
===Example of SQL injection===
The following Java servlet code, used to perform a login function, illustrates the vulnerability by accepting user input without performing adequate input validation or escaping meta-characters:
conn = pool.getConnection( );
String sql = "select * from user where username='" + username +"' and password='" + password + "'";
stmt = conn.createStatement();
rs = stmt.executeQuery(sql);
if (rs.next()) {
loggedIn = true;
out.println("Successfully logged in");
} else {
out.println("Username and/or password not recognized");
}
It is possible for attackers to provide a username containing SQL meta-characters that subvert the intended function of the SQL statement. For example, by providing a username of:
admin' OR '1'='1
and a blank password, the generated SQL statement becomes:
select * from user where username='admin' OR '1'='1' and password=' '
This allows an attacker to log in to the site without supplying a password, since the ‘OR’ expression is always true. Using the same technique attackers can inject other SQL commands which could extract, modify or delete data within the database.
===Attack techniques===
For more information on SQL injection attacks see:
* http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
* http://www.nextgenss.com/papers/advanced_sql_injection.pdf
* http://www.appsecinc.com/presentations/Manipulating_SQL_Server_Using_SQL_Injection.pdf
==Defence Strategy==
To prevent SQL injection, a two pronged approach is recommended:
* Firstly, all data accepted from user input should be thoroughly validated to ensure that the characters received are part of the set of valid characters for that field;
* Secondly, all data acted on by SQL commands should be escaped for meta-characters.
=== Validating Input ===
A general security principle which applies itself well to data validation is that of “deny by default” where data is rejected unless it specifically matches the criteria for known good data. This is also known as a “white list” approach and is the preferred method for performing data validation. It allows one to define a restricted range for valid data and reject everything that does not fit this set. The set of valid data should be constrained by:
* Type – String, integer, unsigned integer, float etc;
* Length;
* Set of character – for example, only alphabetic characters [a-zA-Z]*;
* Format – if appropriate the data could be further constrained by specifying a format, e.g.: \d\d\/\d\d\/\d\d
* Reasonableness – where possible, values should be compared to expected ranges. For example, a customer ordering 1000 televisions could be suspicious.
It is essential that the data validation routines themselves can be trusted, therefore they must be performed on the server side. Client side validation can be performed as a useful user interface feature, but it must be reinforced by server side validation.
Where input validation is performed on the server side will depend largely on the frameworks available. JSF and Struts provide validation functions that are defined in the view layer, while Spring and EJB 3.0 allow validation to be defined in the model. 
Input validation provides the first line of defence in preventing dangerous characters from being processed by the application.
But even if data is constrained in this way it does not solve the meta-character problem: How should the application handle meta-characters that are defined as valid data, but cannot be used in certain processing contexts? For example, the single quote (') character may be a valid character in a surname, but this character cannot simply be used in a string that is used to form an SQL statement. The OWASP Guide project has more information on [[Data Validation]].
=== Escaping Meta-characters ===
All data access techniques provide some means for escaping SQL meta-characters automatically. The important thing to remember is to never construct SQL statements using string concatenation of unchecked input values. The following sections detail how to perform input validation and meta-character escaping using popular data access technologies.
==Prepared Statements==
Variables passed as arguments to prepared statements will automatically be escaped by the JDBC driver. 
Example: ps.1 
String selectStatement = "SELECT * FROM User WHERE userId = ? ";
PreparedStatement prepStmt = con.prepareStatement(selectStatement);
prepStmt.setString(1, userId);
ResultSet rs = prepStmt.executeQuery();

Although Prepared Statements helps in defending against SQL Injection, there are possibilities of SQL Injection attacks through inappropriate usage of Prepared Statements. The example below explains such a scenario where the input variables are passed directly into the Prepared Statement and thereby paving way for SQL Injection attacks. 
Example: ps.2 
<pre>
String strUserName = request.getParameter("Txt_UserName");
PreparedStatement prepStmt = con.prepareStatement("SELECT * FROM user WHERE userId = '+strUserName+'");
</pre>
It is highly recommended to use Bind Variables as mentioned in the example ps.1 above. Usage of PreparedStatement with Bind variables defends SQL Injection attacks and improves the performance.

==Stored Procedures==
==Hibernate==
According to [http://forum.hibernate.org/viewtopic.php?t=960817&start=0&postdays=0&postorder=asc this forum thread] hibernate uses prepared statements, so it is protected from direct sql injection, but it could still be vulnerable to [http://www.owasp.org/index.php/Interpreter_Injection#ORM_Injection injecting HQL statements].

==Ibatis==

Ibatis creates prepared statements for database access.
However, SQL injection is possible in Ibatis if the $$ variable replacement syntax is used. 

Vulnerable: 
<select id=“vuln" resultMap=“myResultMap”> select * from table where id = $value$</select>

The above query is called as follows:
MyBean b = (MyBean)sqlMap.queryForObject("vuln", new Integer(1));

The SQL statement thus created, looks as follows:

select * from table where id = 1

The object passed as parameter is directly fed to the SQL query making it susceptible to SQL injection 

 Secure: 

<select id=“vuln" resultMap=“myResultMap”> select * from table where id = #value#</select>

Using this form instead generates the following SQL

select * from table where id = ?

The value of the parameter is sent directly to the driver and not used to modify the SQL statement itself. 
This approach thwarts SQL injection attacks by automatically escaping SQL meta-characters.

==Spring JDBC==
==EJB 3.0==

== References ==
*[1] [http://research.corsaire.com/whitepapers/060116-a-modular-approach-to-data-validation.pdf A Modular Approach to Data Validation]
*[2] [http://forum.hibernate.org/viewtopic.php?t=960817&start=0&postdays=0&postorder=asc&highlight= Topic: does Hibernate guard against SQL injection?]

[[Category:OWASP Java Project]]

Preventing LDAP Injection in Java

2008-01-14T16:24:49Z

Stephendv: /* Status */

==Status==
'''Broken code! Needs to be corrected.'''

==Approach==
The best way to prevent LDAP injection is to use a positive validation scheme for ensuring that the data going into your queries doesn't contain any attacks. You can read more in [[:Category:OWASP Guide Project|the OWASP Guide]] about input validation.

However, in some cases, it is necessary to include special characters in input that is passed into an LDAP query. In this case, using escaping can prevent the LDAP interpreter from thinking those special characters are actually LDAP query. Rather, the encoding lets the interpreter treat those special characters as data.

Here are a few methods for escaping certain meta-characters in LDAP queries. Both the distinguished name (DN) and the search filter have their own sets of meta-characters. In the case of Java, it is also necessary to escape any JNDI meta-characters, since java uses JNDI to perform LDAP queries.

The examples below present Java methods that could be used to perform this escaping:

Note: This is untested code --[[User:Stephendv|Stephendv]] 05:08, 10 July 2006 (EDT)

The backslash replacement and "," are not working --[[User:Thierry.deleeuw|Thierry.deleeuw]] 17:11, 29 April 2007 (EDT)

public String escapeDN (String name) {
//From RFC 2253 and the / character for JNDI
final char[] META_CHARS = {'+', '"', '<', '>', ';', '/'};
String escapedStr = new String(name);
//Backslash is both a Java and an LDAP escape character, so escape it first
escapedStr = escapedStr.replaceAll("\\\\","\\\\");
//Positional characters - see RFC 2253
escapedStr = escapedStr.replaceAll("^#","\\\\#");
escapedStr = escapedStr.replaceAll("^ | $","\\\\ ");
for (int i=0;i < META_CHARS.length;i++) {
escapedStr = escapedStr.replaceAll("\\"+META_CHARS[i],"\\\\" + META_CHARS[i]);
}
return escapedStr;
}

Note, that the backslash character is a Java String literal and a regular expression escape character.

public String escapeSearchFilter (String filter) {
//From RFC 2254
String escapedStr = new String(filter);
escapedStr = escapedStr.replaceAll("\\\\","\\\\5c");
escapedStr = escapedStr.replaceAll("\\*","\\\\2a");
escapedStr = escapedStr.replaceAll("\$","\\\\28");
escapedStr = escapedStr.replaceAll("\$","\\\\29");
escapedStr = escapedStr.replaceAll("\\"+Character.toString('\u0000'), "\\\\00");
return escapedStr;
}

Optimized version of the previous code (about 8 times faster for escaping LDAP search and 13 times for escapeDN on my PC).--[[User:Thierry.deleeuw|Thierry.deleeuw]] 17:11, 29 April 2007 (EDT)
public static String escapeDN(String name) {
StringBuffer sb = new StringBuffer(); // If using JDK >= 1.5 consider using StringBuilder
if ((name.length() > 0) && ((name.charAt(0) == ' ') || (name.charAt(0) == '#'))) {
sb.append('\\'); // add the leading backslash if needed
}
for (int i = 0; i < name.length(); i++) {
char curChar = name.charAt(i);
switch (curChar) {
case '\\':
sb.append("\\\\");
break;
case ',':
sb.append("\\,");
break;
case '+':
sb.append("\\+");
break;
case '"':
sb.append("\\\"");
break;
case '<':
sb.append("\\<");
break;
case '>':
sb.append("\\>");
break;
case ';':
sb.append("\\;");
break;
default:
sb.append(curChar);
}
}
if ((name.length() > 1) && (name.charAt(name.length() - 1) == ' ')) {
sb.insert(sb.length() - 1, '\\'); // add the trailing backslash if needed
}
return sb.toString();
}
public static final String escapeLDAPSearchFilter(String filter) {
StringBuffer sb = new StringBuffer(); // If using JDK >= 1.5 consider using StringBuilder
for (int i = 0; i < filter.length(); i++) {
char curChar = filter.charAt(i);
switch (curChar) {
case '\\':
sb.append("\\5c");
break;
case '*':
sb.append("\\2a");
break;
case '(':
sb.append("\\28");
break;
case ')':
sb.append("\\29");
break;
case '\u0000':
sb.append("\\00");
break;
default:
sb.append(curChar);
}
}
return sb.toString();
}

Test class:

//escapeDN
assertEquals("No special characters to escape", "Helloé", escapeDN("Helloé"));
assertEquals("leading #", "\\# Helloé", escapeDN("# Helloé"));
assertEquals("leading space", "\\ Helloé", escapeDN(" Helloé"));
assertEquals("trailing space", "Helloé\\ ", escapeDN("Helloé "));
assertEquals("only 3 spaces", "\\ \\ ", escapeDN(" "));
assertEquals("Christmas Tree DN", "\\ Hello\\\\ \\+ \\, \\\"World\\\" \\;\\ ", Test.escapeDN(" Hello\\ + , \"World\" ; "));

assertEquals("No special characters to escape", "Hi This is a test #çà", SecTool.escapeLDAPSearchFilter("Hi This is a test #çà"));
assertEquals("LDAP Christams Tree", "Hi \\28This\\29 = is \\2a a \\5c test # ç à ô", SecTool.escapeLDAPSearchFilter("Hi (This) = is * a \\ test # ç à ô"));

[[Category:OWASP Java Project]]

Preventing LDAP Injection in Java

2008-01-14T16:05:54Z

Stephendv:

==Status==
Broken code

==Approach==
The best way to prevent LDAP injection is to use a positive validation scheme for ensuring that the data going into your queries doesn't contain any attacks. You can read more in [[:Category:OWASP Guide Project|the OWASP Guide]] about input validation.

However, in some cases, it is necessary to include special characters in input that is passed into an LDAP query. In this case, using escaping can prevent the LDAP interpreter from thinking those special characters are actually LDAP query. Rather, the encoding lets the interpreter treat those special characters as data.

Here are a few methods for escaping certain meta-characters in LDAP queries. Both the distinguished name (DN) and the search filter have their own sets of meta-characters. In the case of Java, it is also necessary to escape any JNDI meta-characters, since java uses JNDI to perform LDAP queries.

The examples below present Java methods that could be used to perform this escaping:

Note: This is untested code --[[User:Stephendv|Stephendv]] 05:08, 10 July 2006 (EDT)

The backslash replacement and "," are not working --[[User:Thierry.deleeuw|Thierry.deleeuw]] 17:11, 29 April 2007 (EDT)

public String escapeDN (String name) {
//From RFC 2253 and the / character for JNDI
final char[] META_CHARS = {'+', '"', '<', '>', ';', '/'};
String escapedStr = new String(name);
//Backslash is both a Java and an LDAP escape character, so escape it first
escapedStr = escapedStr.replaceAll("\\\\","\\\\");
//Positional characters - see RFC 2253
escapedStr = escapedStr.replaceAll("^#","\\\\#");
escapedStr = escapedStr.replaceAll("^ | $","\\\\ ");
for (int i=0;i < META_CHARS.length;i++) {
escapedStr = escapedStr.replaceAll("\\"+META_CHARS[i],"\\\\" + META_CHARS[i]);
}
return escapedStr;
}

Note, that the backslash character is a Java String literal and a regular expression escape character.

public String escapeSearchFilter (String filter) {
//From RFC 2254
String escapedStr = new String(filter);
escapedStr = escapedStr.replaceAll("\\\\","\\\\5c");
escapedStr = escapedStr.replaceAll("\\*","\\\\2a");
escapedStr = escapedStr.replaceAll("\$","\\\\28");
escapedStr = escapedStr.replaceAll("\$","\\\\29");
escapedStr = escapedStr.replaceAll("\\"+Character.toString('\u0000'), "\\\\00");
return escapedStr;
}

Optimized version of the previous code (about 8 times faster for escaping LDAP search and 13 times for escapeDN on my PC).--[[User:Thierry.deleeuw|Thierry.deleeuw]] 17:11, 29 April 2007 (EDT)
public static String escapeDN(String name) {
StringBuffer sb = new StringBuffer(); // If using JDK >= 1.5 consider using StringBuilder
if ((name.length() > 0) && ((name.charAt(0) == ' ') || (name.charAt(0) == '#'))) {
sb.append('\\'); // add the leading backslash if needed
}
for (int i = 0; i < name.length(); i++) {
char curChar = name.charAt(i);
switch (curChar) {
case '\\':
sb.append("\\\\");
break;
case ',':
sb.append("\\,");
break;
case '+':
sb.append("\\+");
break;
case '"':
sb.append("\\\"");
break;
case '<':
sb.append("\\<");
break;
case '>':
sb.append("\\>");
break;
case ';':
sb.append("\\;");
break;
default:
sb.append(curChar);
}
}
if ((name.length() > 1) && (name.charAt(name.length() - 1) == ' ')) {
sb.insert(sb.length() - 1, '\\'); // add the trailing backslash if needed
}
return sb.toString();
}
public static final String escapeLDAPSearchFilter(String filter) {
StringBuffer sb = new StringBuffer(); // If using JDK >= 1.5 consider using StringBuilder
for (int i = 0; i < filter.length(); i++) {
char curChar = filter.charAt(i);
switch (curChar) {
case '\\':
sb.append("\\5c");
break;
case '*':
sb.append("\\2a");
break;
case '(':
sb.append("\\28");
break;
case ')':
sb.append("\\29");
break;
case '\u0000':
sb.append("\\00");
break;
default:
sb.append(curChar);
}
}
return sb.toString();
}

Test class:

//escapeDN
assertEquals("No special characters to escape", "Helloé", escapeDN("Helloé"));
assertEquals("leading #", "\\# Helloé", escapeDN("# Helloé"));
assertEquals("leading space", "\\ Helloé", escapeDN(" Helloé"));
assertEquals("trailing space", "Helloé\\ ", escapeDN("Helloé "));
assertEquals("only 3 spaces", "\\ \\ ", escapeDN(" "));
assertEquals("Christmas Tree DN", "\\ Hello\\\\ \\+ \\, \\\"World\\\" \\;\\ ", Test.escapeDN(" Hello\\ + , \"World\" ; "));

assertEquals("No special characters to escape", "Hi This is a test #çà", SecTool.escapeLDAPSearchFilter("Hi This is a test #çà"));
assertEquals("LDAP Christams Tree", "Hi \\28This\\29 = is \\2a a \\5c test # ç à ô", SecTool.escapeLDAPSearchFilter("Hi (This) = is * a \\ test # ç à ô"));

[[Category:OWASP Java Project]]

PDF Attack Filter for Java EE

2008-01-14T15:57:18Z

Stephendv: /* Overview */

==Status==
Released 24/4/2007

==Overview==

This is a filter to block XSS attacks on PDF files served by Java EE applications. The details of the attack are discussed [http://www.gnucitizen.org/blog/danger-danger-danger/ elsewhere]. This filter implements a simple algorithm suggested by Amit Klein. We've placed this software in the public domain to make it easy for anyone to use for any purpose. Please let us know if you're using it!

As an alternative to this, you could change MIME type or the Content-Disposition Header as [http://www.adobe.com/support/security/advisories/apsa07-02.html Adobe security advisory]

==Approach==

This attack relies on having some javascript in an anchor after the url like this: http://www.site.com/file.pdf#blah=javascript:alert(document.cookie);

So the idea is to strip off the anchor. Unfortunately for us, the browser doesn't send the anchor along with the HTTP request. So we can't just strip it off.

Therefore, we're going to use a redirect to steer the browser to a link without the anchor containing the attack. Well, actually it turns out that we have to overwrite the anchor with something else, so we're going to use "#a".

But there's one last problem to overcome. Since the browser doesn't send the anchor, the new request will look exactly like the request generated by the redirect. With no way of telling the original request from the one generated by our redirect, we'll create an infinite loop.

So to differentiate them, we're going to add a temporary token to the URL in the redirect, which we'll verify when it arrives. We don't want an attacker forging this token, so we're going to encrypt the user's source IP address along with a timestamp. If a request shows up for the PDF file without a valid token, we'll reject it. Or actually, we can force it to be saved to disk, thus preventing the attack from working.

This way, only an attacker from the same IP address who can trick you into clicking a link within 10 seconds of creating it can attack you. Not perfect, but certainly raises the bar quite a bit.

==Download==

The source code (one file) and the compiled class file are in a single zip file.

'''[http://www.owasp.org/images/5/59/PDFAttackFilter.zip DOWNLOAD]'''

==Setup==

The first step is to add the filter to our application. All we have to do is put the PDFAttackFilter class on our application's classpath, probably by putting it in the classes folder in WEB-INF. The class file should be in a folder structure that matches the package (org -> owasp -> filters -> PDFAttackFilter). You can extract the class file from the zip file.

Then we just have to add the following to our web.xml. You should paste this in right above your servlet definitions. You'll want to change the mapping so that it only applies to URL's that serve a PDF file. You could use *.pdf, but you may have servlets that stream PDF files that down't end in .pdf.

<pre>
<filter>
<filter-name>PDFAttackFilter</filter-name>
<filter-class>org.owasp.filters.PDFAttackFilter</filter-class>
<init-param>
<param-name>timeoutSeconds</param-name>
<param-value>1</param-value>
</init-param>
<init-param>
<param-name>encryptionPassword</param-name>
<param-value>password</param-value>
</init-param>
<init-param>
<param-name>PDFAttackTokenName</param-name>
<param-value>PDFAttackToken</param-value>
</init-param>
</filter>

<filter-mapping>
<filter-name>PDFAttackFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
</pre>

Depending on your application, it may be difficult to map all the URLs that lead to PDF files. You can map multiple url-patterns to the filter if necessary. In theory, it might be possible to send the redirect only if a response with content-type application/pdf. Then you could map the filter to apply to ALL requests. If there is demand for this feature, let us know.

==Source Code==

This code has been only minimally tested. Please help us verify the approach and the implementation used here.

<pre>
/**
* Software published by the Open Web Application Security Project (http://www.owasp.org)
* This software is in the public domain with no warranty.
*
* @author Jeff Williams <a href="http://www.aspectsecurity.com">Aspect Security</a>
* @created January 4, 2007
*/

package org.owasp.filters;

import java.io.IOException;

import javax.crypto.Cipher;
import javax.crypto.SecretKey;
import javax.crypto.SecretKeyFactory;
import javax.crypto.spec.PBEParameterSpec;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class PDFAttackFilter implements Filter
{

private static sun.misc.BASE64Decoder decoder = new sun.misc.BASE64Decoder();
private static sun.misc.BASE64Encoder encoder = new sun.misc.BASE64Encoder();
private static byte[] salt = { (byte) 0x23, (byte) 0x3f, (byte) 0x28, (byte) 0x00, (byte) 0x11, (byte) 0xc2, (byte) 0xd1, (byte) 0xff };
private static PBEParameterSpec ps = new PBEParameterSpec( salt, 20 );
private static SecretKey secretKey;
private static int timeoutSeconds = 10;
private static String tokenName = "PDFAttackToken";

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException
{
HttpServletRequest req = (HttpServletRequest)request;
HttpServletResponse res = (HttpServletResponse)response;
String token = req.getParameter( tokenName );

try
{

// IF the URL doesn't contain token, then:
// calculate X=encrypt_with_key(server_time, client_IP_address)
// redirect to file.pdf?token=X
// add #a to the end of the url to eliminate any remaining anchors

if ( token == null )
{
String etoken = createToken( req );
String base = req.getRequestURI();
String querystring = req.getQueryString();
if ( querystring != null ) base += "?" + req.getQueryString();
String appender = base.contains( "?" ) ? "&" : "?";
String url = base + appender + tokenName + "=" + etoken + "#a";
res.sendRedirect( res.encodeRedirectURL( url ) );
return;
}

// ELSE IF the URL contains token, then:
// if decrypt(token_query).IP_address==client_IP_address and
// decrypt(token_query).time>server_time-10sec
// serve the PDF resource as an in-line resource

if ( checkToken( token, req ) )
{
chain.doFilter(req, res);
return;
}

// ELSE IF the token doesn't match, then:
// serve the PDF resource as a "save to disk" resource via a proper
// choice of the Content-Type header (and/or an attachment, via
// Content-Disposition).

res.addHeader("Content-Disposition", "Attachment" );
res.setContentType( "application/octet" ); // may be overwritten
chain.doFilter(req, res);
}
catch( Exception e )
{
throw new ServletException( e );
}
}

public void destroy() {
}

public void init(FilterConfig filterConfig) throws ServletException
{
try
{
String tsparam = filterConfig.getInitParameter("timeoutSeconds");
timeoutSeconds = Integer.parseInt(tsparam);

String epparam = filterConfig.getInitParameter("encryptionPassword");
char[] password = epparam.toCharArray();

tokenName = filterConfig.getInitParameter("PDFAttackTokenName");

SecretKeyFactory kf = SecretKeyFactory.getInstance( "PBEWithMD5AndDES" );
secretKey = kf.generateSecret( new javax.crypto.spec.PBEKeySpec( password ) );
}
catch( Exception e )
{
throw new ServletException( e );
}
}

public String createToken( HttpServletRequest request ) throws Exception
{
String address = request.getRemoteAddr();
String time = ""+System.currentTimeMillis();
return encryptString( address + "|" + time );
}

public boolean checkToken( String etoken, HttpServletRequest request ) throws Exception
{
String token = decryptString( etoken );

String currentAddress = request.getRemoteAddr();
String tokenAddress = getAddressFromToken( token );

long currentTime = System.currentTimeMillis();
long tokenTime = getTimeFromToken( token );

return (currentAddress.equals( tokenAddress )) && (tokenTime > currentTime - timeoutSeconds * 1000);
}

public String getAddressFromToken( String token )
{
String address = token.substring( 0, token.indexOf("|") );
return address;
}

public long getTimeFromToken( String token )
{
String date = token.substring( token.indexOf("|") + 1 );
Long longdate = Long.parseLong( date );
return longdate.longValue();
}

public synchronized String decryptString( String str ) throws Exception
{
// Cipher is not threadsafe, so create a new one each time
Cipher passwordDecryptCipher = Cipher.getInstance( "PBEWithMD5AndDES/CBC/PKCS5Padding" );
passwordDecryptCipher.init( Cipher.DECRYPT_MODE, secretKey, ps );
byte[] dec = decoder.decodeBuffer( str.replace( '_', '+') );
byte[] utf8 = passwordDecryptCipher.doFinal( dec );
return new String( utf8, "UTF-8" );
}

public synchronized String encryptString( String str ) throws Exception
{
// Cipher is not threadsafe, so create a new one each time
Cipher passwordEncryptCipher = Cipher.getInstance( "PBEWithMD5AndDES/CBC/PKCS5Padding" );
passwordEncryptCipher.init( Cipher.ENCRYPT_MODE, secretKey, ps );
byte[] utf8 = str.getBytes( "UTF-8" );
byte[] enc = passwordEncryptCipher.doFinal( utf8 );
return encoder.encode( enc ).replace( '+', '_' );
}

}

</pre>

==Compile==

There are not many dependencies here, just the standard Java EE environment. You can compile with:

javac -classpath j2ee.jar -d . *.java

Then just copy the 'org' folder that gets created to the WEB-INF/classes folder.

'''Comment: ''' In the decryptString method, it is necessary to strip the "#a" from the end of the str parameter, otherwise an IllegalBlockSizeException will be thrown with "Input length must be multiple of 8 when decrypting with padded cipher".

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

PDF Attack Filter for Java EE

2008-01-14T15:31:11Z

Stephendv: /* Overview */

==Overview==

This is a filter to block XSS attacks on PDF files served by Java EE applications. The details of the attack are discussed [http://www.gnucitizen.org/blog/danger-danger-danger/ elsewhere]. This filter implements a simple algorithm suggested by Amit Klein. We've placed this software in the public domain to make it easy for anyone to use for any purpose. Please let us know if you're using it!
As an alternative to this, you could change MIME type or the Content-Disposition Header as [http://www.adobe.com/support/security/advisories/apsa07-02.html Adobe security advisory]

==Approach==

This attack relies on having some javascript in an anchor after the url like this: http://www.site.com/file.pdf#blah=javascript:alert(document.cookie);

So the idea is to strip off the anchor. Unfortunately for us, the browser doesn't send the anchor along with the HTTP request. So we can't just strip it off.

Therefore, we're going to use a redirect to steer the browser to a link without the anchor containing the attack. Well, actually it turns out that we have to overwrite the anchor with something else, so we're going to use "#a".

But there's one last problem to overcome. Since the browser doesn't send the anchor, the new request will look exactly like the request generated by the redirect. With no way of telling the original request from the one generated by our redirect, we'll create an infinite loop.

So to differentiate them, we're going to add a temporary token to the URL in the redirect, which we'll verify when it arrives. We don't want an attacker forging this token, so we're going to encrypt the user's source IP address along with a timestamp. If a request shows up for the PDF file without a valid token, we'll reject it. Or actually, we can force it to be saved to disk, thus preventing the attack from working.

This way, only an attacker from the same IP address who can trick you into clicking a link within 10 seconds of creating it can attack you. Not perfect, but certainly raises the bar quite a bit.

==Download==

The source code (one file) and the compiled class file are in a single zip file.

'''[http://www.owasp.org/images/5/59/PDFAttackFilter.zip DOWNLOAD]'''

==Setup==

The first step is to add the filter to our application. All we have to do is put the PDFAttackFilter class on our application's classpath, probably by putting it in the classes folder in WEB-INF. The class file should be in a folder structure that matches the package (org -> owasp -> filters -> PDFAttackFilter). You can extract the class file from the zip file.

Then we just have to add the following to our web.xml. You should paste this in right above your servlet definitions. You'll want to change the mapping so that it only applies to URL's that serve a PDF file. You could use *.pdf, but you may have servlets that stream PDF files that down't end in .pdf.

<pre>
<filter>
<filter-name>PDFAttackFilter</filter-name>
<filter-class>org.owasp.filters.PDFAttackFilter</filter-class>
<init-param>
<param-name>timeoutSeconds</param-name>
<param-value>1</param-value>
</init-param>
<init-param>
<param-name>encryptionPassword</param-name>
<param-value>password</param-value>
</init-param>
<init-param>
<param-name>PDFAttackTokenName</param-name>
<param-value>PDFAttackToken</param-value>
</init-param>
</filter>

<filter-mapping>
<filter-name>PDFAttackFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
</pre>

Depending on your application, it may be difficult to map all the URLs that lead to PDF files. You can map multiple url-patterns to the filter if necessary. In theory, it might be possible to send the redirect only if a response with content-type application/pdf. Then you could map the filter to apply to ALL requests. If there is demand for this feature, let us know.

==Source Code==

This code has been only minimally tested. Please help us verify the approach and the implementation used here.

<pre>
/**
* Software published by the Open Web Application Security Project (http://www.owasp.org)
* This software is in the public domain with no warranty.
*
* @author Jeff Williams <a href="http://www.aspectsecurity.com">Aspect Security</a>
* @created January 4, 2007
*/

package org.owasp.filters;

import java.io.IOException;

import javax.crypto.Cipher;
import javax.crypto.SecretKey;
import javax.crypto.SecretKeyFactory;
import javax.crypto.spec.PBEParameterSpec;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class PDFAttackFilter implements Filter
{

private static sun.misc.BASE64Decoder decoder = new sun.misc.BASE64Decoder();
private static sun.misc.BASE64Encoder encoder = new sun.misc.BASE64Encoder();
private static byte[] salt = { (byte) 0x23, (byte) 0x3f, (byte) 0x28, (byte) 0x00, (byte) 0x11, (byte) 0xc2, (byte) 0xd1, (byte) 0xff };
private static PBEParameterSpec ps = new PBEParameterSpec( salt, 20 );
private static SecretKey secretKey;
private static int timeoutSeconds = 10;
private static String tokenName = "PDFAttackToken";

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException
{
HttpServletRequest req = (HttpServletRequest)request;
HttpServletResponse res = (HttpServletResponse)response;
String token = req.getParameter( tokenName );

try
{

// IF the URL doesn't contain token, then:
// calculate X=encrypt_with_key(server_time, client_IP_address)
// redirect to file.pdf?token=X
// add #a to the end of the url to eliminate any remaining anchors

if ( token == null )
{
String etoken = createToken( req );
String base = req.getRequestURI();
String querystring = req.getQueryString();
if ( querystring != null ) base += "?" + req.getQueryString();
String appender = base.contains( "?" ) ? "&" : "?";
String url = base + appender + tokenName + "=" + etoken + "#a";
res.sendRedirect( res.encodeRedirectURL( url ) );
return;
}

// ELSE IF the URL contains token, then:
// if decrypt(token_query).IP_address==client_IP_address and
// decrypt(token_query).time>server_time-10sec
// serve the PDF resource as an in-line resource

if ( checkToken( token, req ) )
{
chain.doFilter(req, res);
return;
}

// ELSE IF the token doesn't match, then:
// serve the PDF resource as a "save to disk" resource via a proper
// choice of the Content-Type header (and/or an attachment, via
// Content-Disposition).

res.addHeader("Content-Disposition", "Attachment" );
res.setContentType( "application/octet" ); // may be overwritten
chain.doFilter(req, res);
}
catch( Exception e )
{
throw new ServletException( e );
}
}

public void destroy() {
}

public void init(FilterConfig filterConfig) throws ServletException
{
try
{
String tsparam = filterConfig.getInitParameter("timeoutSeconds");
timeoutSeconds = Integer.parseInt(tsparam);

String epparam = filterConfig.getInitParameter("encryptionPassword");
char[] password = epparam.toCharArray();

tokenName = filterConfig.getInitParameter("PDFAttackTokenName");

SecretKeyFactory kf = SecretKeyFactory.getInstance( "PBEWithMD5AndDES" );
secretKey = kf.generateSecret( new javax.crypto.spec.PBEKeySpec( password ) );
}
catch( Exception e )
{
throw new ServletException( e );
}
}

public String createToken( HttpServletRequest request ) throws Exception
{
String address = request.getRemoteAddr();
String time = ""+System.currentTimeMillis();
return encryptString( address + "|" + time );
}

public boolean checkToken( String etoken, HttpServletRequest request ) throws Exception
{
String token = decryptString( etoken );

String currentAddress = request.getRemoteAddr();
String tokenAddress = getAddressFromToken( token );

long currentTime = System.currentTimeMillis();
long tokenTime = getTimeFromToken( token );

return (currentAddress.equals( tokenAddress )) && (tokenTime > currentTime - timeoutSeconds * 1000);
}

public String getAddressFromToken( String token )
{
String address = token.substring( 0, token.indexOf("|") );
return address;
}

public long getTimeFromToken( String token )
{
String date = token.substring( token.indexOf("|") + 1 );
Long longdate = Long.parseLong( date );
return longdate.longValue();
}

public synchronized String decryptString( String str ) throws Exception
{
// Cipher is not threadsafe, so create a new one each time
Cipher passwordDecryptCipher = Cipher.getInstance( "PBEWithMD5AndDES/CBC/PKCS5Padding" );
passwordDecryptCipher.init( Cipher.DECRYPT_MODE, secretKey, ps );
byte[] dec = decoder.decodeBuffer( str.replace( '_', '+') );
byte[] utf8 = passwordDecryptCipher.doFinal( dec );
return new String( utf8, "UTF-8" );
}

public synchronized String encryptString( String str ) throws Exception
{
// Cipher is not threadsafe, so create a new one each time
Cipher passwordEncryptCipher = Cipher.getInstance( "PBEWithMD5AndDES/CBC/PKCS5Padding" );
passwordEncryptCipher.init( Cipher.ENCRYPT_MODE, secretKey, ps );
byte[] utf8 = str.getBytes( "UTF-8" );
byte[] enc = passwordEncryptCipher.doFinal( utf8 );
return encoder.encode( enc ).replace( '+', '_' );
}

}

</pre>

==Compile==

There are not many dependencies here, just the standard Java EE environment. You can compile with:

javac -classpath j2ee.jar -d . *.java

Then just copy the 'org' folder that gets created to the WEB-INF/classes folder.

'''Comment: ''' In the decryptString method, it is necessary to strip the "#a" from the end of the str parameter, otherwise an IllegalBlockSizeException will be thrown with "Input length must be multiple of 8 when decrypting with padded cipher".

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

Java gotchas

2008-01-14T15:18:38Z

Stephendv:

==Status==
Released 14/1/2008

== Equality ==
Object equality is tested using the == operator, while value equality is tested using the .equals(Object) method. For example:
String one = new String("abc");
String two = new String("abc");
String three = one;
if (one != two) System.out.println("The two objects are not the same.");
if (one.equals(two)) System.out.println("But they do contain the same value");
if (one == three) System.out.println("These two are the same, because they use the same reference.");

The output is:
The two objects are not the same.
But they do contain the same value
These two are the same, because they use the same reference.

Also, be aware that:

String abc = "abc"

and

String abc = new String("abc");

are different. For example, consider the following:

String letters = "abc";
String moreLetters = "abc";

System.out.println(letters==moreLetters);

The output is:

true

This is due to the compiler and runtime efficiency. In the compiled class file only one set of data "abc" is stored, not two. In this situation only one object is created, therefore the equality is true between these object. However, consider this:

String data = new String("123");
String moreData = new String("123");

System.out.println(data==moreData);

The output is:

false

Even though one set of data "123" is stored in the class this is still treated differently at runtime. An explicit instantiation is used to create the String objects. Therefore, in this case, two objects have been created, so the equality is false. It is important to note that "==" is always used for object equality and does not ever refer to the values in an object. Always use .equals when checking looking for a "meaningful" comparison.

== Immutable Objects / Wrapper Class Caching ==
Since Java 5, wrapper class caching was introduced. The following is an examination of the cache created by an inner class, IntegerCache, located in the Integer cache. For example, the following code will create a cache:

Integer myNumber = 10
or
Integer myNumber = Integer.valueOf(10);

256 Integer objects are created in the range of -128 to 127 which are all stored in an Integer array. This caching functionality can be seen by looking at the inner class, IntegerCache, which is found in Integer:

<pre>
private static class IntegerCache
{
private IntegerCache(){}

static final Integer cache[] = new Integer[-(-128) + 127 + 1];

static
{
for(int i = 0; i < cache.length; i++)
cache[i] = new Integer(i - 128);
}
}

public static Integer valueOf(int i)
{
final int offset = 128;
if (i >= -128 && i <= 127) // must cache
{
return IntegerCache.cache[i + offset];
}
return new Integer(i);
}
</pre>

So when creating an object using Integer.valueOf or directly assigning a value to an Integer within the range of -128 to 127 the same object will be returned. Therefore, consider the following example:

Integer i = 100;
Integer p = 100;
if (i == p) System.out.println("i and p are the same.");
if (i != p) System.out.println("i and p are different.");
if(i.equals(p)) System.out.println("i and p contain the same value.");

The output is:
i and p are the same.
i and p contain the same value.

It is important to note that object i and p only equate to true because they are the same object, the comparison is not based on the value, it is based on object equality. If Integer i and p are outside the range of -128 or 127 the cache is not used, therefore new objects are created. When doing a comparison for value always use the “.equals” method. It is also important to note that instantiating an Integer does not create this caching. So consider the following example:

Integer i = new Integer (100);
Integer p = new Integer(100);
if(i==p) System.out.println(“i and p are the same object”);
if(i.equals(p)) System.out.println(“ i and p contain the same value”);

In this circumstance, the output is only:

i and p contain the same value

Remember that “==” is always used for object equality, it has not been overloaded for comparing unboxed values.

This behavior is documented in the [http://java.sun.com/docs/books/jls Java Language Specification] [http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.7 section 5.1.7]. Quoting from there:
:If the value ''p'' being boxed is true, false, a byte, a char in the range \u0000 to \u007f, or an int or short number between -128 and 127, then let ''r1'' and ''r2'' be the results of any two boxing conversions of ''p''. It is always the case that ''r1'' == ''r2''.

The other wrapper classes (Byte, Short, Long, Character) also contain this caching mechanism. The Byte, Short and Long all contain the same caching principle to the Integer object. The Character class caches from 0 to 127. The negative cache is not created for the Character wrapper as these values do not represent a corresponding character. There is no caching for the Float object.

BigDecimal also uses caching but uses a different mechanism. While the other objects contain a inner class to deal with caching this is not true for BigDecimal, the caching is pre-defined in a static array and only covers 11 numbers, 0 to 10:

// Cache of common small BigDecimal values.
private static final BigDecimal zeroThroughTen[] = {
new BigDecimal(BigInteger.ZERO, 0, 0),
new BigDecimal(BigInteger.ONE, 1, 0),
new BigDecimal(BigInteger.valueOf(2), 2, 0),
new BigDecimal(BigInteger.valueOf(3), 3, 0),
new BigDecimal(BigInteger.valueOf(4), 4, 0),
new BigDecimal(BigInteger.valueOf(5), 5, 0),
new BigDecimal(BigInteger.valueOf(6), 6, 0),
new BigDecimal(BigInteger.valueOf(7), 7, 0),
new BigDecimal(BigInteger.valueOf(8), 8, 0),
new BigDecimal(BigInteger.valueOf(9), 9, 0),
new BigDecimal(BigInteger.TEN, 10, 0),
};

As per Java Language Specification(JLS) the values discussed above are stored as immutable wrapper objects. This caching has been created because it is assumed these values / objects are used more frequently.

== Incrementing values ==
Be careful of the post-increment operator:

int x = 5;
x = x++;
System.out.println( x );

The output is:

5

Remember that the assignment completes before the increment, hence post-increment. Using the pre-increment will update the value
before the assignment. For example:

int x = 5;
x = ++x;
System.out.println( x );

The output is:

6

== Garbage Collection ==

By overriding "finalize()" will allow you to define you own code for what is potentially the same concept as a destructor. There are a couple of important points to remember:

* "finalize()" will only ever by called once (at most) by the Garbage Collector.
* It is never a guarantee that "finalize()" will be called i.e that an object will be garbage collected.
* By overriding "finalize()" you can prevent an object from ever being deleted. For example, the object passes a reference of itself to another object.
* Garbage collection behaviour differs between JVMs.

== Boolean Assignment ==

Everyone appreciates the difference between "==" and "=" in Java. However, typos and mistakes are made, often the compiler will catch them. However, consider the following:

boolean theTruth = false;
if (theTruth = true)
{
System.out.println("theTruth is true");
}
else
{
System.out.println("theTruth is false;");
}

The result of any assignment expression is the value of the variable following the assignment. Therefore, the above will always result in "theTruth is true". This only applies to booleans, so for example the following will not compile and would therefore be caught by the compiler:

int i = 1;
if(i=0) {}

As "i" is and integer the comparison would evaluate to (i=0) as 0 is the result of the assignment. A boolean would be expected, due the "if" statement.

== Conditions ==

Be on the look out for any nested "else if". Consider the following code example:

int x = 3;
if (x==5) {}
else if (x<9)
{
System.out.println("x is less than 9");
}
else if (x<6)
{
System.out.println("x is less than 6");
}
else
{
System.out.println("else");
}

Produces the output:

x is less then 9

So even though the second else if would equate to "true" it is never reached. This is because once an "else if" succeeds the remaining conditions will be not be processed.

[[Category:OWASP Java Project]]

Java Server Faces

2008-01-14T15:17:45Z

Stephendv: /* Status */

==Status==
Released 14/1/2008

==Author==
Sam Reghenzi
==Web security.. before you start ==

This document is about security in web applications developed using the Java Server Faces (JSF) framework. The reader should be aware of the meaning of common terms of both JSF (converters, validators, managed beans) and web security (injection etc.)

==JSF Standards and roles==
JavaServer Faces (JSF) is a Java-based Web application framework that implements the Model-View-Controller pattern and simplifies the development of web interfaces for Java EE applications.

In a standard MVC JSF are meant to provide the V (of view) and part of the C (of Control). JSF components can present almost any basic interface model. The framework also provides part of the Control layer including:
* Navigation Handling
* Error Handling
* Action and event Management
* Input validation
* Value conversion
These elements are defined by the JSF standard (JCP 127) so that any attacker will have knowledge of the architecture and life cycle of a JSF based application. JSF does not implement it's own security model but instead relies on standard JEE security. This means that both application server security model, JAAS or other ACL implementations can be used with the JSF framework without any integration effort. But Access Control is just one part of security - all aspects should be implemented in a secure manner in order to consider the application itself secure.

==Client-side state saving==
A JSF application can save the state of its components in the client response or on the server. Saving state on the client may be required because some users turn off cookies support, but it can increase response times when connections are slow. Saving state on the server may have the disadvantage of high memory consumption for the user, but it does minimize bandwidth requirements.
Since client-side state saving stores data in the client , it should be used wisely, or not used at all. An attacker that can manipulate a user's data could manage a data tampering or worst, a privilege escalation exploit. Unencrypted data is quite easy to manipulate and most of the client-side saved data are serialized Java objects which can contain a wealth of sensitive data. If you plan to use client-side state saving carefully consider which information you decide to store in the POJO/DTO in order to minimise these risks.
==Components==
===Converters===
Converter could be a source of threat since it converts string in Java objects. An attacker could inject malicious code or tampered data to make the converter itself misbehave and expose protected data. The converter system is not insecure by itself, but conversion, since it is a security touch point for business logic and persistent data, should be handled carefully. Input should '''always''' be validated '''after''' being converted. In JSF lingo you should '''always''' have a validator if a conversion occurs. See next section on how to implement a security aware validator.

===Validators===
Validation is your chance to verify that the input is as expected. This means that the input should be validated both from a domain view and from a security view. If input represents a string that in your domain should be from 10 to 254 characters long, the same string should be validated also to prevent SQL Injection and XSS attacks. Since many security checks are done using dictionary algorithms it's useful to have a validator that implements those checks and extends it to implement your domain validator.
For example:

public class TenToHundredsValidator extends SecureValidator() {
public void validate(...) {

super.validate(...); // Do security checks

domainvalidate(....);
}
}

===ManagedBeans===
Managed beans are the gears of JSF based application. Developers can access FacesContext statically and this is potentially dangerous. This is a common short cut for everything in the JSF layer, but manipulating this data could be harmful. Relying on security principals, and software engineering, is always a good approach.
Calls such as:
FacesContext.getCurrentInstance().getExternalContext().getRequestParameter("name")
are dangerous because the whole validation stack is bypassed. You can read parameters but consider them as tainted input. Use Validators described above also if you are not in the validation phase . Validators are also an effective way to refactor your validation code and to prevent code repetition.
FacesContext also allows access to user principal data; this data could be used to verify if the current user can actually execute the business logic in the managed Bean.
This practice should be adopted in favour of rendering or not the commandLinks that lead to the action of the managed Bean. A structured adoption of an execution based security framework , such as ACEGI (see the Appendix), could be a good enforcement of the security of the managed bean.
===Custom components===
If the use of custom components is required in the application, the security depends on how the components are developed. Third party components should be delivered with a security report and support from the specific vendor or community.
If you develop custom components you should be aware of the same old security issues of web development:
* Do not thrust request parameter
* Do not thrust cookies
* Always consider that session could be hijacked
Since the component tree is assembled server side it can be trusted so if your custom component needs to read data from a sibling component it should be considered a safe operation although you will have to make assumptions on element names of the tree.
==Implementations==
Since more than one JSF Implementation exists, bugs of the implementation should be first on the security list.

===MyFaces===
There aren't major or critical security bugs registered in the current stable release of MyFaces (1.1.5). Client state saving is still the weak point and should be used wisely. My Faces comes also with a Security Extension (http://wiki.apache.org/myfaces/SecurityContext) that allows to safely and easily retrieve authenticated user details.

The MyFaces resource filter could be a source of threat. It is designed to expose resources from a jar file and could therefore, be considered, potentially dangerous. Note there aren't any claimed security flaws nor exploits in the resource filter, but the nature of this component makes it a good target for attackers. Since all it has to do is serve data it is recommended that a dispatcher be added to the filter mapping element. This should lower the possibility of an attacker successfully manipulating the server request.
For more information see: http://myfaces.apache.org/tomahawk/extensionsFilter.htm

There is also an easy way to enable encryption when using ''client save state''

<context-param>
<param-name>org.apache.myfaces.secret</param-name>
<param-value>NzY1NDMyMTA=</param-value>
</context-param>

Supported encryption methods are BlowFish, 3DES, AES and are definde bya a context parameter

<context-param>
<param-name>org.apache.myfaces.algorithm</param-name>
<param-value>Blowfish</param-value>
</context-param>

You can find mre info at http://wiki.apache.org/myfaces/Secure_Your_Application

===SUN Reference Implementation===
Quoting from the documentation:
''There are several ways for a web application to store session state on the client tier. One possible solution is to use Cookies to store the state on the client. However, cookies have limitations in size and are not ideal in cases where you want to store session state on the client. The state that needs to be stored on the client is first serialized into a byte array. This byte array is then encrypted using industrial-strength 3DES with cipher-block-chaining (CBC) and an initialization vector. To make the content tamper-resistant, we then create a message authentication code (using SHA1 algorithm) from the encrypted content and the initialization vector. The initialization vector, the message authentication code, and the encrypted content is then combined in a single byte array. Finally, this resulting byte array is converted into a base64 string which is stored in a hidden FORM field on the client.
This solution is secure because it uses a strong crypto algorithm and also uses a MAC for tamper-resistance. We also generate all the random numbers (for example, to generate the initialization vectors and the password) using the cryptographically-secure SecureRandom class. Note that the encryption keys are NEVER sent to the client or sent on the wire. These keys are used only on the server-side to encrypt and decrypt the state. One challenge is to decide what encryption keys to use. The encryption keys should not be known to the client, but still be associated with the client. We solve this problem by generating these keys from a password that is generated randomly and stored in the HttpSession. This strategy for key generation through password is pluggable in our solution and can be changed if needed.''

===ICE Faces===

Starting from the idea that AJAX on Its Own Doesn't Corrupt Web Security ICE faces implements a component suite with ajax support by maintainig a coninus sync bettween the dom sent to the browser and a dom rapresentation on the server. javascript is used to send commands to the server and invoke the logic in the java layer. Since dom model and javascript is involved a Javascript debugging tool with value injection or dom injection capability could be of some use in pick loking the app.

As stated in ICEFaces manual " the client is untrusted, SO DON'T TRUST IT!!" : it means that is all ups to the application designer to implement a robust security logic behind the scenes.
In another point of view th developer could focus on implement server side security since with the server-side-dom architecture the thin client is even thinner.

The component thath refresh the two dom , caled IntervalRenderer, uses a persistent ServletRequest stored on the server. Unfortunately, this request does not contain sufficient information to perform the isUserInRole() check.
This kind of check is possible only on stadar render request phase.

To address this, a small amount of integration will be required either between ICEfaces and acegi-security or ICEfaces and the application server. Acegi-security (see appendix one ) is likely preferable as it will be more portable.

==Apendix I==

===ACEGI Integration===

Acegi Security is a powerful, flexible security solution for enterprise software, with a particular emphasis on applications that use Spring. If used in combination with jsf, the managed beans could become more "security aware" since acegi do not only perform authentication but also authorization in business layer. Acegi is a convenient way to manage security in all the layers of our application. This is a valuable thing especially when authorization is strongly coupled with business logic (approval work flows etc).

In order to use a custom JSF-Acegi login we have to provide a valid Security Context (''userName'' and ''password'' are properties of the managed bean)

UsernamePasswordAuthenticationToken authReq = new UsernamePasswordAuthenticationToken(userName, password);
Authentication auth = getAuthenticationManager().authenticate(authReq);
SecurityContext secCtx = SecurityContextHolder.getContext();
secCtx.setAuthentication(auth);

We can override the standard ACEGI navigation with custom, logic driven, navigation reading security context and routing the outcome.

More information can be found at here [http://www.javakaffee.de/blog/2006/07/04/jsfacegi-authentication-with-a-backing-bean/]

ACEGI can be integrated also in the rendering via custom components [http://cagataycivici.wordpress.com/2006/01/19/acegi_jsf_components_hit_the/] which basically wrap the standard ACEGI tag library in JSF components. This conveniently solve the ''stage zero'' of profiling: display or not a widget in the page.

Including a JSF based form for login in a page could be a little tricky, bu using MyFaces tomahawk components it can be done easely.

The form will look like

<%@ taglib uri="http://myfaces.apache.org/tomahawk" prefix="t"%>
<t:inputText id="j_username" forceId="true" value="#{backingBean.customerId}" size="40" maxlength="80"></t:inputText>
<t:inputSecret id="j_password" forceId="true" value="#{backingBean.password}" size="40" maxlength="80" redisplay="true"></t:inputSecret>
<h:commandButton action="login" value="#{messages.page_signon}"/>
<h:messages id="messages" layout="table" globalOnly="true" showSummary="true" showDetail="false"/>

A navigation rule to follow ACEGI requirements

<navigation-rule>
<from-view-id>/login.jsp</from-view-id>
<navigation-case>
<from-outcome>login</from-outcome>
<to-view-id>/j_acegi_security_check.jsp</to-view-id>
</navigation-case>
</navigation-rule>

And finaly ACEGI is told which page do the login

<bean id="formAuthenticationProcessingFilter" class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
<property name="filterProcessesUrl">
<value>/j_acegi_security_check.jsp</value>
</property>
<property name="authenticationFailureUrl">
<value>/login.faces</value>
</property>
...

[[Category:OWASP Java Project]]

Talk:Java Server Faces

2008-01-14T15:16:34Z

Stephendv: /* EUxx discussion */

== EUxx discussion ==
I think the blog by EUxx missed some of the details of the implementation. Note that while the MAC and the IV are known, there is still a secret key known to the server used in the MAC that prevents the client from generating a new MAC. This is a fairly common pattern. You can see Inderjeet's response at:
http://weblogs.java.net/blog/inder/archive/2005/05/securing_webapp.html

I think we should either take this section out, or expand on why its an issue.
[[User:Ebing|Ebing]] 14:30, 11 June 2007 (EDT)

Moved it here, till the author can correct [[User:Stephendv|Stephendv]] 10:16, 14 January 2008 (EST)

===EUxx===
http://jroller.com/page/eu stated the following:
''It seems there are few gaps in this claim. Data sent to the client look like this: [MAC][IV][ENCDATA] As you can see, MAC and IV values are known to the client. It means that nothing can stop client from tampering ENCDATA block and then generate a new MAC. This can be improved with using signature based on public key scheme instead of MAC. However that will increase amount of computations for building message data and will require to store public key in HttpSession. Another potential security issue is related to the usage of block cipher. By the nature of Object Serialization Stream Protocol, every encrypted plain text will have common patterns. More over, because client can indirectly control content of the encrypted data by submitting specially crafted requests to the server, that some data from request will be sent back in encrypted form). This can open the door for "known-text" attack and I'm not sure how good "industrial-strength" ciphers against such attacks. Again, this can be improved by generating secure key for every request, but it will create additional troubles on concurrent scenarios and will require that key will be distributed across the cluster on every change. So, I think that above issues has to be investigated more deep and proper security analysis must be done before suggesting any solution that is using some forms of cryptography.''

Java Server Faces

2008-01-14T15:15:44Z

Stephendv: /* EUxx */

==Status==
'''Content to be finalised. Needs reviewing'''
==Author==
Sam Reghenzi
==Web security.. before you start ==

This document is about security in web applications developed using the Java Server Faces (JSF) framework. The reader should be aware of the meaning of common terms of both JSF (converters, validators, managed beans) and web security (injection etc.)

==JSF Standards and roles==
JavaServer Faces (JSF) is a Java-based Web application framework that implements the Model-View-Controller pattern and simplifies the development of web interfaces for Java EE applications.

In a standard MVC JSF are meant to provide the V (of view) and part of the C (of Control). JSF components can present almost any basic interface model. The framework also provides part of the Control layer including:
* Navigation Handling
* Error Handling
* Action and event Management
* Input validation
* Value conversion
These elements are defined by the JSF standard (JCP 127) so that any attacker will have knowledge of the architecture and life cycle of a JSF based application. JSF does not implement it's own security model but instead relies on standard JEE security. This means that both application server security model, JAAS or other ACL implementations can be used with the JSF framework without any integration effort. But Access Control is just one part of security - all aspects should be implemented in a secure manner in order to consider the application itself secure.

==Client-side state saving==
A JSF application can save the state of its components in the client response or on the server. Saving state on the client may be required because some users turn off cookies support, but it can increase response times when connections are slow. Saving state on the server may have the disadvantage of high memory consumption for the user, but it does minimize bandwidth requirements.
Since client-side state saving stores data in the client , it should be used wisely, or not used at all. An attacker that can manipulate a user's data could manage a data tampering or worst, a privilege escalation exploit. Unencrypted data is quite easy to manipulate and most of the client-side saved data are serialized Java objects which can contain a wealth of sensitive data. If you plan to use client-side state saving carefully consider which information you decide to store in the POJO/DTO in order to minimise these risks.
==Components==
===Converters===
Converter could be a source of threat since it converts string in Java objects. An attacker could inject malicious code or tampered data to make the converter itself misbehave and expose protected data. The converter system is not insecure by itself, but conversion, since it is a security touch point for business logic and persistent data, should be handled carefully. Input should '''always''' be validated '''after''' being converted. In JSF lingo you should '''always''' have a validator if a conversion occurs. See next section on how to implement a security aware validator.

===Validators===
Validation is your chance to verify that the input is as expected. This means that the input should be validated both from a domain view and from a security view. If input represents a string that in your domain should be from 10 to 254 characters long, the same string should be validated also to prevent SQL Injection and XSS attacks. Since many security checks are done using dictionary algorithms it's useful to have a validator that implements those checks and extends it to implement your domain validator.
For example:

public class TenToHundredsValidator extends SecureValidator() {
public void validate(...) {

super.validate(...); // Do security checks

domainvalidate(....);
}
}

===ManagedBeans===
Managed beans are the gears of JSF based application. Developers can access FacesContext statically and this is potentially dangerous. This is a common short cut for everything in the JSF layer, but manipulating this data could be harmful. Relying on security principals, and software engineering, is always a good approach.
Calls such as:
FacesContext.getCurrentInstance().getExternalContext().getRequestParameter("name")
are dangerous because the whole validation stack is bypassed. You can read parameters but consider them as tainted input. Use Validators described above also if you are not in the validation phase . Validators are also an effective way to refactor your validation code and to prevent code repetition.
FacesContext also allows access to user principal data; this data could be used to verify if the current user can actually execute the business logic in the managed Bean.
This practice should be adopted in favour of rendering or not the commandLinks that lead to the action of the managed Bean. A structured adoption of an execution based security framework , such as ACEGI (see the Appendix), could be a good enforcement of the security of the managed bean.
===Custom components===
If the use of custom components is required in the application, the security depends on how the components are developed. Third party components should be delivered with a security report and support from the specific vendor or community.
If you develop custom components you should be aware of the same old security issues of web development:
* Do not thrust request parameter
* Do not thrust cookies
* Always consider that session could be hijacked
Since the component tree is assembled server side it can be trusted so if your custom component needs to read data from a sibling component it should be considered a safe operation although you will have to make assumptions on element names of the tree.
==Implementations==
Since more than one JSF Implementation exists, bugs of the implementation should be first on the security list.

===MyFaces===
There aren't major or critical security bugs registered in the current stable release of MyFaces (1.1.5). Client state saving is still the weak point and should be used wisely. My Faces comes also with a Security Extension (http://wiki.apache.org/myfaces/SecurityContext) that allows to safely and easily retrieve authenticated user details.

The MyFaces resource filter could be a source of threat. It is designed to expose resources from a jar file and could therefore, be considered, potentially dangerous. Note there aren't any claimed security flaws nor exploits in the resource filter, but the nature of this component makes it a good target for attackers. Since all it has to do is serve data it is recommended that a dispatcher be added to the filter mapping element. This should lower the possibility of an attacker successfully manipulating the server request.
For more information see: http://myfaces.apache.org/tomahawk/extensionsFilter.htm

There is also an easy way to enable encryption when using ''client save state''

<context-param>
<param-name>org.apache.myfaces.secret</param-name>
<param-value>NzY1NDMyMTA=</param-value>
</context-param>

Supported encryption methods are BlowFish, 3DES, AES and are definde bya a context parameter

<context-param>
<param-name>org.apache.myfaces.algorithm</param-name>
<param-value>Blowfish</param-value>
</context-param>

You can find mre info at http://wiki.apache.org/myfaces/Secure_Your_Application

===SUN Reference Implementation===
Quoting from the documentation:
''There are several ways for a web application to store session state on the client tier. One possible solution is to use Cookies to store the state on the client. However, cookies have limitations in size and are not ideal in cases where you want to store session state on the client. The state that needs to be stored on the client is first serialized into a byte array. This byte array is then encrypted using industrial-strength 3DES with cipher-block-chaining (CBC) and an initialization vector. To make the content tamper-resistant, we then create a message authentication code (using SHA1 algorithm) from the encrypted content and the initialization vector. The initialization vector, the message authentication code, and the encrypted content is then combined in a single byte array. Finally, this resulting byte array is converted into a base64 string which is stored in a hidden FORM field on the client.
This solution is secure because it uses a strong crypto algorithm and also uses a MAC for tamper-resistance. We also generate all the random numbers (for example, to generate the initialization vectors and the password) using the cryptographically-secure SecureRandom class. Note that the encryption keys are NEVER sent to the client or sent on the wire. These keys are used only on the server-side to encrypt and decrypt the state. One challenge is to decide what encryption keys to use. The encryption keys should not be known to the client, but still be associated with the client. We solve this problem by generating these keys from a password that is generated randomly and stored in the HttpSession. This strategy for key generation through password is pluggable in our solution and can be changed if needed.''

===ICE Faces===

Starting from the idea that AJAX on Its Own Doesn't Corrupt Web Security ICE faces implements a component suite with ajax support by maintainig a coninus sync bettween the dom sent to the browser and a dom rapresentation on the server. javascript is used to send commands to the server and invoke the logic in the java layer. Since dom model and javascript is involved a Javascript debugging tool with value injection or dom injection capability could be of some use in pick loking the app.

As stated in ICEFaces manual " the client is untrusted, SO DON'T TRUST IT!!" : it means that is all ups to the application designer to implement a robust security logic behind the scenes.
In another point of view th developer could focus on implement server side security since with the server-side-dom architecture the thin client is even thinner.

The component thath refresh the two dom , caled IntervalRenderer, uses a persistent ServletRequest stored on the server. Unfortunately, this request does not contain sufficient information to perform the isUserInRole() check.
This kind of check is possible only on stadar render request phase.

To address this, a small amount of integration will be required either between ICEfaces and acegi-security or ICEfaces and the application server. Acegi-security (see appendix one ) is likely preferable as it will be more portable.

==Apendix I==

===ACEGI Integration===

Acegi Security is a powerful, flexible security solution for enterprise software, with a particular emphasis on applications that use Spring. If used in combination with jsf, the managed beans could become more "security aware" since acegi do not only perform authentication but also authorization in business layer. Acegi is a convenient way to manage security in all the layers of our application. This is a valuable thing especially when authorization is strongly coupled with business logic (approval work flows etc).

In order to use a custom JSF-Acegi login we have to provide a valid Security Context (''userName'' and ''password'' are properties of the managed bean)

UsernamePasswordAuthenticationToken authReq = new UsernamePasswordAuthenticationToken(userName, password);
Authentication auth = getAuthenticationManager().authenticate(authReq);
SecurityContext secCtx = SecurityContextHolder.getContext();
secCtx.setAuthentication(auth);

We can override the standard ACEGI navigation with custom, logic driven, navigation reading security context and routing the outcome.

More information can be found at here [http://www.javakaffee.de/blog/2006/07/04/jsfacegi-authentication-with-a-backing-bean/]

ACEGI can be integrated also in the rendering via custom components [http://cagataycivici.wordpress.com/2006/01/19/acegi_jsf_components_hit_the/] which basically wrap the standard ACEGI tag library in JSF components. This conveniently solve the ''stage zero'' of profiling: display or not a widget in the page.

Including a JSF based form for login in a page could be a little tricky, bu using MyFaces tomahawk components it can be done easely.

The form will look like

<%@ taglib uri="http://myfaces.apache.org/tomahawk" prefix="t"%>
<t:inputText id="j_username" forceId="true" value="#{backingBean.customerId}" size="40" maxlength="80"></t:inputText>
<t:inputSecret id="j_password" forceId="true" value="#{backingBean.password}" size="40" maxlength="80" redisplay="true"></t:inputSecret>
<h:commandButton action="login" value="#{messages.page_signon}"/>
<h:messages id="messages" layout="table" globalOnly="true" showSummary="true" showDetail="false"/>

A navigation rule to follow ACEGI requirements

<navigation-rule>
<from-view-id>/login.jsp</from-view-id>
<navigation-case>
<from-outcome>login</from-outcome>
<to-view-id>/j_acegi_security_check.jsp</to-view-id>
</navigation-case>
</navigation-rule>

And finaly ACEGI is told which page do the login

<bean id="formAuthenticationProcessingFilter" class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
<property name="filterProcessesUrl">
<value>/j_acegi_security_check.jsp</value>
</property>
<property name="authenticationFailureUrl">
<value>/login.faces</value>
</property>
...

[[Category:OWASP Java Project]]

Java Security Frameworks

2008-01-14T15:07:29Z

Stephendv:

A list of third party (i.e. not part of Java SE or EE) security frameworks.

==Enterprise==
* [http://www.owasp.org/index.php/ESAPI OWASP Enterprise Security API] a new OWASP project to provide all essential security services under one roof.

== Access Control (Authentication and Authorisation) ==
* [http://www.acegisecurity.org/ Acegi Security] - Acegi Security is a powerful, flexible security solution for enterprise software, with a particular emphasis on applications that use Spring. Using Acegi Security provides your applications with comprehensive authentication, authorization, instance-based access control, channel security and human user detection capabilities.
* [http://sourceforge.net/projects/jguard jGuard] - jGuard is written in java. his goal is to provide a security framework based on jaas (java authentication and authorization security) . this framework is written for web and standalone applications, to resolve simply, access control problems.
== Encryption ==
* [http://www.bouncycastle.org/ Bouncycastle] - Lightweight Java cryptography APIs
* [http://www.jasypt.org/ Jasypt] - Jasypt is a java library which allows the developer to add basic encryption capabilities to his/her projects with minimum effort, and without the need of having deep knowledge on how cryptography works.

[[Category:OWASP Java Project]]

How to perform HTML entity encoding in Java

2008-01-14T14:52:40Z

Stephendv:

==Status==
Released 14/1/2008

==Overview==

Injection attacks rely on the fact that interpreters take data and execute it as commands. If an attacker can modify the data that's sent to an interpreter, they may be able to make it misbehave. One way to help prevent this from happening is to encode the attacker's data in such a way that the interpreter will not get confused. [http://www.w3.org/TR/html401/sgml/entities.html HTML entity encoding] is just such an encoding mechanism for many interpreters.

This is not a guarantee by the way. It's almost certain that someone, probably from the XML/Web Services world, will create an engine that performs HTML entity decoding automatically, thus reintroducing the injection threat. However, for the time being, HTML entity encoding seems to work pretty well to prevent many types of injection.

==Status==
Released 14/1/2007

==Approach==

We're going to implement a simple little method that encodes special characters. The nice .NET folks over at Microsoft had the foresight to build this into their platform, but the Java community seems to resist adding validation to the Java EE environment despite all the security issues that it could solve. View layers such as Java Server Faces, Spring-MVC, WebWork and others automatically perform HTML encoding through custom tags.

The best place for this method is in some kind of ValidationEngine, but since it's a good candidate for being static, it doesn't matter what class it ends up in that much.

Note that this implementation doesn't produce the special characters like & lt; or & gt; - but it's not difficult to implement with a simple lookup table.

public static String HTMLEntityEncode( String s )
{
StringBuffer buf = new StringBuffer();
int len = (s == null ? -1 : s.length());

for ( int i = 0; i < len; i++ )
{
char c = s.charAt( i );
if ( c>='a' && c<='z' || c>='A' && c<='Z' || c>='0' && c<='9' )
{
buf.append( c );
}
else
{
buf.append( "&#" + (int)c + ";" );
}
}
return buf.toString();
}

==Libraries==
* The Jakara Commons Lang package has a generic class for performing a wide range of [http://commons.apache.org/lang/api-release/org/apache/commons/lang/StringEscapeUtils.html String escaping functions].
* jTidy includes an [http://jtidy.sourceforge.net/multiproject/jtidyservlet/apidocs/org/w3c/tidy/servlet/util/HTMLEncode.html HTMLEncode class] for performing HTML encoding.

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

How to perform HTML entity encoding in Java

2008-01-14T14:52:19Z

Stephendv: /* Overview */

==Status
Released 14/1/2008

==Overview==

Injection attacks rely on the fact that interpreters take data and execute it as commands. If an attacker can modify the data that's sent to an interpreter, they may be able to make it misbehave. One way to help prevent this from happening is to encode the attacker's data in such a way that the interpreter will not get confused. [http://www.w3.org/TR/html401/sgml/entities.html HTML entity encoding] is just such an encoding mechanism for many interpreters.

This is not a guarantee by the way. It's almost certain that someone, probably from the XML/Web Services world, will create an engine that performs HTML entity decoding automatically, thus reintroducing the injection threat. However, for the time being, HTML entity encoding seems to work pretty well to prevent many types of injection.

==Status==
Released 14/1/2007

==Approach==

We're going to implement a simple little method that encodes special characters. The nice .NET folks over at Microsoft had the foresight to build this into their platform, but the Java community seems to resist adding validation to the Java EE environment despite all the security issues that it could solve. View layers such as Java Server Faces, Spring-MVC, WebWork and others automatically perform HTML encoding through custom tags.

The best place for this method is in some kind of ValidationEngine, but since it's a good candidate for being static, it doesn't matter what class it ends up in that much.

Note that this implementation doesn't produce the special characters like & lt; or & gt; - but it's not difficult to implement with a simple lookup table.

public static String HTMLEntityEncode( String s )
{
StringBuffer buf = new StringBuffer();
int len = (s == null ? -1 : s.length());

for ( int i = 0; i < len; i++ )
{
char c = s.charAt( i );
if ( c>='a' && c<='z' || c>='A' && c<='Z' || c>='0' && c<='9' )
{
buf.append( c );
}
else
{
buf.append( "&#" + (int)c + ";" );
}
}
return buf.toString();
}

==Libraries==
* The Jakara Commons Lang package has a generic class for performing a wide range of [http://commons.apache.org/lang/api-release/org/apache/commons/lang/StringEscapeUtils.html String escaping functions].
* jTidy includes an [http://jtidy.sourceforge.net/multiproject/jtidyservlet/apidocs/org/w3c/tidy/servlet/util/HTMLEncode.html HTMLEncode class] for performing HTML encoding.

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

Talk:How to perform HTML entity encoding in Java

2008-01-14T14:51:11Z

Stephendv: /* Status */

==Status==
Released [[User:Stephendv|Stephendv]] 09:51, 14 January 2008 (EST)

==Reviewers==
* Dave Read

==General Discussion==

The Apache Jakarta Commons Lang package (as of version 2.2) contains a StringEscapeUtils class that contains this functionality. See the escapeHtml(String) method. The documentation states:

Escapes the characters in a String using HTML entities.

Supports all known HTML 4.0 entities, including funky accents. Note that the commonly used apostrophe escape character (') is not a legal entity and so is not supported).

Talk:How to perform HTML entity encoding in Java

2008-01-14T14:45:28Z

Stephendv: /* Reviewers */

==Status==
Needs review

==Reviewers==
* Dave Read

==General Discussion==

The Apache Jakarta Commons Lang package (as of version 2.2) contains a StringEscapeUtils class that contains this functionality. See the escapeHtml(String) method. The documentation states:

Escapes the characters in a String using HTML entities.

Supports all known HTML 4.0 entities, including funky accents. Note that the commonly used apostrophe escape character (') is not a legal entity and so is not supported).

How to perform HTML entity encoding in Java

2008-01-14T14:38:12Z

Stephendv: /* Approach */

==Overview==

Injection attacks rely on the fact that interpreters take data and execute it as commands. If an attacker can modify the data that's sent to an interpreter, they may be able to make it misbehave. One way to help prevent this from happening is to encode the attacker's data in such a way that the interpreter will not get confused. [http://www.w3.org/TR/html401/sgml/entities.html HTML entity encoding] is just such an encoding mechanism for many interpreters.

This is not a guarantee by the way. It's almost certain that someone, probably from the XML/Web Services world, will create an engine that performs HTML entity decoding automatically, thus reintroducing the injection threat. However, for the time being, HTML entity encoding seems to work pretty well to prevent many types of injection.

==Status==
Released 14/1/2007

==Approach==

We're going to implement a simple little method that encodes special characters. The nice .NET folks over at Microsoft had the foresight to build this into their platform, but the Java community seems to resist adding validation to the Java EE environment despite all the security issues that it could solve. View layers such as Java Server Faces, Spring-MVC, WebWork and others automatically perform HTML encoding through custom tags.

The best place for this method is in some kind of ValidationEngine, but since it's a good candidate for being static, it doesn't matter what class it ends up in that much.

Note that this implementation doesn't produce the special characters like & lt; or & gt; - but it's not difficult to implement with a simple lookup table.

public static String HTMLEntityEncode( String s )
{
StringBuffer buf = new StringBuffer();
int len = (s == null ? -1 : s.length());

for ( int i = 0; i < len; i++ )
{
char c = s.charAt( i );
if ( c>='a' && c<='z' || c>='A' && c<='Z' || c>='0' && c<='9' )
{
buf.append( c );
}
else
{
buf.append( "&#" + (int)c + ";" );
}
}
return buf.toString();
}

==Libraries==
* The Jakara Commons Lang package has a generic class for performing a wide range of [http://commons.apache.org/lang/api-release/org/apache/commons/lang/StringEscapeUtils.html String escaping functions].
* jTidy includes an [http://jtidy.sourceforge.net/multiproject/jtidyservlet/apidocs/org/w3c/tidy/servlet/util/HTMLEncode.html HTMLEncode class] for performing HTML encoding.

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

Talk:How to add validation logic to HttpServletRequest

2008-01-14T14:27:54Z

Stephendv: /* Status */

==Status==
Reviewed and released [[User:Stephendv|Stephendv]] 09:27, 14 January 2008 (EST)

==Reviewers==
* Stephen de Vries

==General Discussion==

Talk:How to add validation logic to HttpServletRequest

2008-01-14T14:22:32Z

Stephendv: /* Reviewers */

==Status==
Needs review

==Reviewers==
* Stephen de Vries

==General Discussion==

Hashing Java

2008-01-14T13:10:45Z

Stephendv:

== Status ==
Released 14/1/2008
==Introduction==

Most of today’s applications use login/password in order to authenticate. Users often use the same login/password for different kinds of applications. If the couple is stolen, everybody can access all the applications the user has access to.

Too often passwords are stored as clear text. Thus the password can be read directly by the database’s administrator, super users or SQL Injection attack etc. The backup media is also vulnerable.
In order to solve this problem, passwords must be stored encrypted. Two kinds of encryption are available:
* One way functions (SHA-256 SHA-1 MD5, ..;) also known as Hashing functions
* Reversible encryption functions (DES, AES, …).
However, the reversible property of encryption function is useless for credentials storing (cf. OWASP Guide v2.0.1) :

''Passwords are secrets. There is no reason to decrypt them under any circumstances. Helpdesk staff should be able to set new passwords (with an audit trail, obviously), not read back old passwords. Therefore, there is no reason to store passwords in a reversible form.''

==Definition of cryptographic Hashing function:==
A Hash function creates a fixed length small fingerprint (or message digest) from an unlimited input string.

hash(X) ->Y X is a infinite set and Y is a finite set.

A good cryptographic Hash function must have these properties:
* Preimage resistant : From the function output y it must impossible to compute the input x such that hash(x)=y.
* Second preimage resistant : from an input x1 it must impossible to compute another input x2 (different of x1) such that hash(x1)=hash(x2).
* Collision resistant : It must be difficult to find two inputs x1 and x2 (x1<>x2) such that hash(x1)=hash(x2).

'''Sample java code :'''
import java.security.MessageDigest;

public byte[] getHash(String password) throws NoSuchAlgorithmException {
MessageDigest digest = MessageDigest.getInstance("SHA-1");
digest.reset();
byte[] input = digest.digest(password.getBytes("UTF-8"));
}

==Credential storage.==

If the password’s digest is stored in a database, an attacker should be unable to recover the password thanks to the preimage resistance. The only way to go past this would be a [[Brute force attack|brute force attack]], i.e. computing the hash of all possible passwords or a dictionary attack, i.e. computing all the often used password.

==Why add salt ? ==

There are two drawbacks to choosing to only store the password’s hash:
* It is possible to identify two identical passwords.
* Due to the birthday paradox (http://en.wikipedia.org/wiki/Birthday_paradox), the attacker can find a password very quickly especially if the number of password is important in the database.

In order to solve these problems, a salt can be concatenated to the password before the digest operation.

A salt is a random number of a fixed length. This salt must be different for each stored entry. It must be stored as clear text next to the hashed password.

In this configuration, an attacker must handle a brute force attack on each individual password. The database is now birthday attack resistant.

A 64 bits salt is recommended in RSA PKCS5 standard.

'''Sample java code :'''
import java.security.MessageDigest;

public byte[] getHash(String password, byte[] salt) throws NoSuchAlgorithmException {
MessageDigest digest = MessageDigest.getInstance("SHA-256");
digest.reset();
digest.update(salt);
return digest.digest(password.getBytes("UTF-8"));
}

==Hardening against the attacker's attack==

To slow down the computation it is recommended to iterate the hash operation n times. While hashing the password n times does slow down hashing for both attackers and typical users, typical users don't really notice it being that hashing is such a small percentage of their total time interacting with the system. On the other hand, an attacker trying to crack passwords spends nearly 100% of their time hashing so hashing n times gives the appearance of slowing the attacker down by a factor of n while not noticeably affecting the typical user.
A minimum of 1000 operations is recommended in RSA PKCS5 standard.

The stored password looks like this :
Hash(hash(hash(hash(……….hash(password||salt)))))))))))))))

To authenticate a user, the operation same as above must be performed, followed by a comparison of the two hashes.

The hash function you need to use depends of your security policy. SHA-256 or SHA-512 is recommended for long term storage.

'''Sample java code :'''
import java.security.*;

public byte[] getHash(int iterationNb, String password, byte[] salt) throws NoSuchAlgorithmException {
MessageDigest digest = MessageDigest.getInstance("SHA-1");
digest.reset();
digest.update(salt);
byte[] input = digest.digest(password.getBytes("UTF-8"));
for (int i = 0; i < iterationNb; i++) {
digest.reset();
input = digest.digest(input);
}
return input;
}

==Complete Java Sample==
In order to create the table needed by this application, call the method creerTable().
It creates a TABLE called CREDENTIAL, with these fields :
* LOGIN VARCHAR (100) PRIMARY KEY
* PASSWORD VARCHAR (32)
* SALT VARCHAR (32)

In this database, the password and the salt are stored in Base64 representation.

The method ''authenticate'' is used in order to authenticate a user, the method ''createUser'' is used to create a new user.

package org.psafix.memopwd;

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.io.IOException;
import sun.misc.BASE64Decoder;
import sun.misc.BASE64Encoder;
import java.sql.*;
import java.util.Arrays;
import java.security.SecureRandom;

public class Owasp {
private final static int ITERATION_NUMBER = 1000;

public Owasp() {
}

/**
* Authenticates the user with a given login and password
* If password and/or login is null then always returns false.
* If the user does not exist in the database returns false.
* @param con Connection An open connection to a databse
* @param login String The login of the user
* @param password String The password of the user
* @return boolean Returns true if the user is authenticated, false otherwise
* @throws SQLException If the database is inconsistent or unavailable (
* (Two users with the same login, salt or digested password altered etc.)
* @throws NoSuchAlgorithmException If the algorithm SHA-1 is not supported by the JVM
*/
public boolean authenticate(Connection con, String login, String password)
throws SQLException, NoSuchAlgorithmException{
boolean authenticated=false;
PreparedStatement ps = null;
ResultSet rs = null;
try {
boolean userExist = true;
// INPUT VALIDATION
if (login==null||password==null){
// TIME RESISTANT ATTACK
// Computation time is equal to the time needed by a legitimate user
userExist = false;
login="";
password="";
}

ps = con.prepareStatement("SELECT PASSWORD, SALT FROM CREDENTIAL WHERE LOGIN = ?");
ps.setString(1, login);
rs = ps.executeQuery();
String digest, salt;
if (rs.next()) {
digest = rs.getString("PASSWORD");
salt = rs.getString("SALT");
// DATABASE VALIDATION
if (digest == null || salt == null) {
throw new SQLException("Database inconsistant Salt or Digested Password altered");
}
if (rs.next()) { // Should not append, because login is the primary key
throw new SQLException("Database inconsistent two CREDENTIALS with the same LOGIN");
}
} else { // TIME RESISTANT ATTACK (Even if the user does not exist the
// Computation time is equal to the time needed for a legitimate user
digest = "000000000000000000000000000=";
salt = "00000000000=";
userExist = false;
}

byte[] bDigest = base64ToByte(digest);
byte[] bSalt = base64ToByte(salt);

// Compute the new DIGEST
byte[] proposedDigest = getHash(ITERATION_NUMBER, password, bSalt);

return Arrays.equals(proposedDigest, bDigest) && userExist;
} catch (IOException ex){
throw new SQLException("Database inconsistant Salt or Digested Password altered");
}
finally{
close(rs);
close(ps);
}
}

/**
* Inserts a new user in the database
* @param con Connection An open connection to a databse
* @param login String The login of the user
* @param password String The password of the user
* @return boolean Returns true if the login and password are ok (not null and length(login)<=100
* @throws SQLException If the database is unavailable
* @throws NoSuchAlgorithmException If the algorithm SHA-1 or the SecureRandom is not supported by the JVM
*/
public boolean createUser(Connection con, String login, String password)
throws SQLException, NoSuchAlgorithmException
{
PreparedStatement ps = null;
try {
if (login!=null&&password!=null&&login.length()<=100){
// Uses a secure Random not a simple Random
SecureRandom random = SecureRandom.getInstance("SHA1PRNG");
// Salt generation 64 bits long
byte[] bSalt = new byte[8];
random.nextBytes(bSalt);
// Digest computation
byte[] bDigest = getHash(ITERATION_NUMBER,password,bSalt);
String sDigest = byteToBase64(bDigest);
String sSalt = byteToBase64(bSalt);

ps = con.prepareStatement("INSERT INTO CREDENTIAL (LOGIN, PASSWORD, SALT) VALUES (?,?,?)");
ps.setString(1,login);
ps.setString(2,sDigest);
ps.setString(3,sSalt);
ps.executeUpdate();
return true;
} else {
return false;
}
} finally {
close(ps);
}
}

/**
* From a password, a number of iterations and a salt,
* returns the corresponding digest
* @param iterationNb int The number of iterations of the algorithm
* @param password String The password to encrypt
* @param salt byte[] The salt
* @return byte[] The digested password
* @throws NoSuchAlgorithmException If the algorithm doesn't exist
*/
public byte[] getHash(int iterationNb, String password, byte[] salt) throws NoSuchAlgorithmException {
MessageDigest digest = MessageDigest.getInstance("SHA-1");
digest.reset();
digest.update(salt);
byte[] input = digest.digest(password.getBytes("UTF-8"));
for (int i = 0; i < iterationNb; i++) {
digest.reset();
input = digest.digest(input);
}
return input;
}

public void creerTable(Connection con) throws SQLException{
Statement st = null;
try {
st = con.createStatement();
st.execute("CREATE TABLE CREDENTIAL (LOGIN VARCHAR(100) PRIMARY KEY, PASSWORD VARCHAR(32) NOT NULL, SALT VARCHAR(32) NOT NULL)");
} finally {
close(st);
}
}

/**
* Closes the current statement
* @param ps Statement
*/
public void close(Statement ps) {
if (ps!=null){
try {
ps.close();
} catch (SQLException ignore) {
}
}
}

/**
* Closes the current resultset
* @param ps Statement
*/
public void close(ResultSet rs) {
if (rs!=null){
try {
rs.close();
} catch (SQLException ignore) {
}
}
}

/**
* From a base 64 representation, returns the corresponding byte[]
* @param data String The base64 representation
* @return byte[]
* @throws IOException
*/
public static byte[] base64ToByte(String data) throws IOException {
BASE64Decoder decoder = new BASE64Decoder();
return decoder.decodeBuffer(data);
}

/**
* From a byte[] returns a base 64 representation
* @param data byte[]
* @return String
* @throws IOException
*/
public static String byteToBase64(byte[] data){
BASE64Encoder endecoder = new BASE64Encoder();
return endecoder.encode(data);
}

}

[[Category:OWASP Java Project]]

Talk:Hashing Java

2008-01-14T13:10:00Z

Stephendv: /* Reviewers */

==Status==
Needs review

==Reviewers==
* Neil Smithline

==General Discussion==
I use a very similar scheme in my applications, but 2 points that came to mind whilst reading.
#Iterations of at least 1000 times seemed a bit excessive, but it is in the standard and I'm in no way qualified to critise.
#Instead of storing salt in it's own field I usually include it amongst the password (i.e characters 2, 4, 7, 13, 17, 19) to make it that bit harder to even find the salt value. I generally hex encode the hashes as well to make them a bit easier to work with. Assuming decompiled code is available (as an attacker has gained access to the password hashes) this extra salt hiding may not serve any useless purpose.
:--------------
:I think that the above comment about hiding the bits in the password should just tossed. First, it is basically arguing security by obscurity - never a good practice. Second, it states that the bit hiding isn't helpful when the source code is available. Being that this article is discussing hashing in "Java" specifically and Java decompilation is a well-known and freely available technology, it seems that there is no need to mention hiding of the salt unless it is in reference to other languages. Eg: "In languages other than Java, where obtaining the source code can be difficult and reading the machine code is awkward, hiding the bits of the salt within the hashed password might provide some extra security.(And comments probably should be signed. Four tilde's "~ ~ ~ ~", without the intervening spaces, adds your username and timestamps the comment.)
:[[User:Neil Smithline|Neil Smithline]] 16:46, 13 April 2007 (EDT)
::I'm advocating information hiding, not security by obscurity, albeit a fine line. The case where source is available makes it a pointless exercise from a security perspective, but imagine a badly written webapp provides access to the database. Showing the use of different salts and then making the salt value obvious allows an attacker to perform dictionary attacks. Hiding the salt within the encrypted password makes this almost impossible. [[User:Dledmonds|Darren]] 12:34, 17 April 2007 (EDT)

== Huh? Repetitive hashing only affects the attacker? ==

The article states ([[Hashing_Java#Hardening against the attacker's attack]]):
:To slow down the computation it is recommended to iterate the hash operation n times. Because hashing is a fast operation, it slows down by a n factor an attacker but not a legitimate user.
I find the second sentence so awkward to parse that I'm not sure if it is incorrect, I'm mis-parsing it, or I'm not understanding what it is saying. My understanding is that doing the hash ''n'' times slows down both the attacker, the user, and anyone else who wants to hash, by a factor of ''n'' every time they hash. The key here is that most of what a typical user does is not authentication, and most of authentication is not password validation. Other tasks such as database lookups, permission gathering, and session initialization tend to be much slower than password validation (which likely happens entirely in memory in a tight loop and thereby flies by comparison to the DB-based operations). So, while hashing the password ''n'' times does slow down '''hashing''' for both attackers '''and''' typical users, typical users don't really notice it being that hashing is such a small percentage of their total time interacting with the system. On the other hand, an attacker trying to crack passwords spends nearly 100% of their time hashing so hashing ''n'' times '''gives the appearance''' of slowing the attacker down by a factor of ''n'' while not noticeably affecting the typical user.

If someone else takes a look at my comment and the article and agrees, then it should probably just be changed. I would have done this myself but I'm concerned (although not very concerned) that I might be misunderstanding the text.

[[User:Neil Smithline|Neil Smithline]] 17:09, 13 April 2007 (EDT)

Agree, have changed it - [[User:Stephendv|Stephendv]] 08:06, 14 January 2008 (EST)

== Char to byte ==

password.getBytes() should be password.getBytes("UTF-8")

Changed. [[User:Stephendv|Stephendv]] 08:09, 14 January 2008 (EST)

Talk:Hashing Java

2008-01-14T13:09:31Z

Stephendv: /* Char to byte */

==Status==
Needs review

==Reviewers==
* ?

==General Discussion==
I use a very similar scheme in my applications, but 2 points that came to mind whilst reading.
#Iterations of at least 1000 times seemed a bit excessive, but it is in the standard and I'm in no way qualified to critise.
#Instead of storing salt in it's own field I usually include it amongst the password (i.e characters 2, 4, 7, 13, 17, 19) to make it that bit harder to even find the salt value. I generally hex encode the hashes as well to make them a bit easier to work with. Assuming decompiled code is available (as an attacker has gained access to the password hashes) this extra salt hiding may not serve any useless purpose.
:--------------
:I think that the above comment about hiding the bits in the password should just tossed. First, it is basically arguing security by obscurity - never a good practice. Second, it states that the bit hiding isn't helpful when the source code is available. Being that this article is discussing hashing in "Java" specifically and Java decompilation is a well-known and freely available technology, it seems that there is no need to mention hiding of the salt unless it is in reference to other languages. Eg: "In languages other than Java, where obtaining the source code can be difficult and reading the machine code is awkward, hiding the bits of the salt within the hashed password might provide some extra security.(And comments probably should be signed. Four tilde's "~ ~ ~ ~", without the intervening spaces, adds your username and timestamps the comment.)
:[[User:Neil Smithline|Neil Smithline]] 16:46, 13 April 2007 (EDT)
::I'm advocating information hiding, not security by obscurity, albeit a fine line. The case where source is available makes it a pointless exercise from a security perspective, but imagine a badly written webapp provides access to the database. Showing the use of different salts and then making the salt value obvious allows an attacker to perform dictionary attacks. Hiding the salt within the encrypted password makes this almost impossible. [[User:Dledmonds|Darren]] 12:34, 17 April 2007 (EDT)

== Huh? Repetitive hashing only affects the attacker? ==

The article states ([[Hashing_Java#Hardening against the attacker's attack]]):
:To slow down the computation it is recommended to iterate the hash operation n times. Because hashing is a fast operation, it slows down by a n factor an attacker but not a legitimate user.
I find the second sentence so awkward to parse that I'm not sure if it is incorrect, I'm mis-parsing it, or I'm not understanding what it is saying. My understanding is that doing the hash ''n'' times slows down both the attacker, the user, and anyone else who wants to hash, by a factor of ''n'' every time they hash. The key here is that most of what a typical user does is not authentication, and most of authentication is not password validation. Other tasks such as database lookups, permission gathering, and session initialization tend to be much slower than password validation (which likely happens entirely in memory in a tight loop and thereby flies by comparison to the DB-based operations). So, while hashing the password ''n'' times does slow down '''hashing''' for both attackers '''and''' typical users, typical users don't really notice it being that hashing is such a small percentage of their total time interacting with the system. On the other hand, an attacker trying to crack passwords spends nearly 100% of their time hashing so hashing ''n'' times '''gives the appearance''' of slowing the attacker down by a factor of ''n'' while not noticeably affecting the typical user.

If someone else takes a look at my comment and the article and agrees, then it should probably just be changed. I would have done this myself but I'm concerned (although not very concerned) that I might be misunderstanding the text.

[[User:Neil Smithline|Neil Smithline]] 17:09, 13 April 2007 (EDT)

Agree, have changed it - [[User:Stephendv|Stephendv]] 08:06, 14 January 2008 (EST)

== Char to byte ==

password.getBytes() should be password.getBytes("UTF-8")

Changed. [[User:Stephendv|Stephendv]] 08:09, 14 January 2008 (EST)

Talk:Hashing Java

2008-01-14T13:06:05Z

Stephendv: /* Huh? Repetitive hashing only affects the attacker? */

Hashing Java

2008-01-14T13:05:25Z

Stephendv: /* Hardening against the attacker's attack */

==Introduction :==

Most of today’s applications use login/password in order to authenticate. Users often use the same login/password for different kinds of applications. If the couple is stolen, everybody can access all the applications the user has access to.

Too often passwords are stored as clear text. Thus the password can be read directly by the database’s administrator, super users or SQL Injection attack etc. The backup media is also vulnerable.
In order to solve this problem, passwords must be stored encrypted. Two kinds of encryption are available:
* One way functions (SHA-256 SHA-1 MD5, ..;) also known as Hashing functions
* Reversible encryption functions (DES, AES, …).
However, the reversible property of encryption function is useless for credentials storing (cf. OWASP Guide v2.0.1) :

''Passwords are secrets. There is no reason to decrypt them under any circumstances. Helpdesk staff should be able to set new passwords (with an audit trail, obviously), not read back old passwords. Therefore, there is no reason to store passwords in a reversible form.''

==Definition of cryptographic Hashing function:==
A Hash function creates a fixed length small fingerprint (or message digest) from an unlimited input string.

hash(X) ->Y X is a infinite set and Y is a finite set.

A good cryptographic Hash function must have these properties:
* Preimage resistant : From the function output y it must impossible to compute the input x such that hash(x)=y.
* Second preimage resistant : from an input x1 it must impossible to compute another input x2 (different of x1) such that hash(x1)=hash(x2).
* Collision resistant : It must be difficult to find two inputs x1 and x2 (x1<>x2) such that hash(x1)=hash(x2).

'''Sample java code :'''
import java.security.MessageDigest;

public byte[] getHash(String password) throws NoSuchAlgorithmException {
MessageDigest digest = MessageDigest.getInstance("SHA-1");
digest.reset();
byte[] input = digest.digest(password.getBytes());
}

==Credential storage.==

If the password’s digest is stored in a database, an attacker should be unable to recover the password thanks to the preimage resistance. The only way to go past this would be a [[Brute force attack|brute force attack]], i.e. computing the hash of all possible passwords or a dictionary attack, i.e. computing all the often used password.

==Why add salt ? ==

There are two drawbacks to choosing to only store the password’s hash:
* It is possible to identify two identical passwords.
* Due to the birthday paradox (http://en.wikipedia.org/wiki/Birthday_paradox), the attacker can find a password very quickly especially if the number of password is important in the database.

In order to solve these problems, a salt can be concatenated to the password before the digest operation.

A salt is a random number of a fixed length. This salt must be different for each stored entry. It must be stored as clear text next to the hashed password.

In this configuration, an attacker must handle a brute force attack on each individual password. The database is now birthday attack resistant.

A 64 bits salt is recommended in RSA PKCS5 standard.

'''Sample java code :'''
import java.security.MessageDigest;

public byte[] getHash(String password, byte[] salt) throws NoSuchAlgorithmException {
MessageDigest digest = MessageDigest.getInstance("SHA-256");
digest.reset();
digest.update(salt);
return digest.digest(password.getBytes());
}

==Hardening against the attacker's attack==

To slow down the computation it is recommended to iterate the hash operation n times. While hashing the password n times does slow down hashing for both attackers and typical users, typical users don't really notice it being that hashing is such a small percentage of their total time interacting with the system. On the other hand, an attacker trying to crack passwords spends nearly 100% of their time hashing so hashing n times gives the appearance of slowing the attacker down by a factor of n while not noticeably affecting the typical user.
A minimum of 1000 operations is recommended in RSA PKCS5 standard.

The stored password looks like this :
Hash(hash(hash(hash(……….hash(password||salt)))))))))))))))

To authenticate a user, the operation same as above must be performed, followed by a comparison of the two hashes.

The hash function you need to use depends of your security policy. SHA-256 or SHA-512 is recommended for long term storage.

'''Sample java code :'''
import java.security.*;

public byte[] getHash(int iterationNb, String password, byte[] salt) throws NoSuchAlgorithmException {
MessageDigest digest = MessageDigest.getInstance("SHA-1");
digest.reset();
digest.update(salt);
byte[] input = digest.digest(password.getBytes());
for (int i = 0; i < iterationNb; i++) {
digest.reset();
input = digest.digest(input);
}
return input;
}

==Complete Java Sample==
In order to create the table needed by this application, call the method creerTable().
It creates a TABLE called CREDENTIAL, with these fields :
* LOGIN VARCHAR (100) PRIMARY KEY
* PASSWORD VARCHAR (32)
* SALT VARCHAR (32)

In this database, the password and the salt are stored in Base64 representation.

The method ''authenticate'' is used in order to authenticate a user, the method ''createUser'' is used to create a new user.

package org.psafix.memopwd;

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.io.IOException;
import sun.misc.BASE64Decoder;
import sun.misc.BASE64Encoder;
import java.sql.*;
import java.util.Arrays;
import java.security.SecureRandom;

public class Owasp {
private final static int ITERATION_NUMBER = 1000;

public Owasp() {
}

/**
* Authenticates the user with a given login and password
* If password and/or login is null then always returns false.
* If the user does not exist in the database returns false.
* @param con Connection An open connection to a databse
* @param login String The login of the user
* @param password String The password of the user
* @return boolean Returns true if the user is authenticated, false otherwise
* @throws SQLException If the database is inconsistent or unavailable (
* (Two users with the same login, salt or digested password altered etc.)
* @throws NoSuchAlgorithmException If the algorithm SHA-1 is not supported by the JVM
*/
public boolean authenticate(Connection con, String login, String password)
throws SQLException, NoSuchAlgorithmException{
boolean authenticated=false;
PreparedStatement ps = null;
ResultSet rs = null;
try {
boolean userExist = true;
// INPUT VALIDATION
if (login==null||password==null){
// TIME RESISTANT ATTACK
// Computation time is equal to the time needed by a legitimate user
userExist = false;
login="";
password="";
}

ps = con.prepareStatement("SELECT PASSWORD, SALT FROM CREDENTIAL WHERE LOGIN = ?");
ps.setString(1, login);
rs = ps.executeQuery();
String digest, salt;
if (rs.next()) {
digest = rs.getString("PASSWORD");
salt = rs.getString("SALT");
// DATABASE VALIDATION
if (digest == null || salt == null) {
throw new SQLException("Database inconsistant Salt or Digested Password altered");
}
if (rs.next()) { // Should not append, because login is the primary key
throw new SQLException("Database inconsistent two CREDENTIALS with the same LOGIN");
}
} else { // TIME RESISTANT ATTACK (Even if the user does not exist the
// Computation time is equal to the time needed for a legitimate user
digest = "000000000000000000000000000=";
salt = "00000000000=";
userExist = false;
}

byte[] bDigest = base64ToByte(digest);
byte[] bSalt = base64ToByte(salt);

// Compute the new DIGEST
byte[] proposedDigest = getHash(ITERATION_NUMBER, password, bSalt);

return Arrays.equals(proposedDigest, bDigest) && userExist;
} catch (IOException ex){
throw new SQLException("Database inconsistant Salt or Digested Password altered");
}
finally{
close(rs);
close(ps);
}
}

/**
* Inserts a new user in the database
* @param con Connection An open connection to a databse
* @param login String The login of the user
* @param password String The password of the user
* @return boolean Returns true if the login and password are ok (not null and length(login)<=100
* @throws SQLException If the database is unavailable
* @throws NoSuchAlgorithmException If the algorithm SHA-1 or the SecureRandom is not supported by the JVM
*/
public boolean createUser(Connection con, String login, String password)
throws SQLException, NoSuchAlgorithmException
{
PreparedStatement ps = null;
try {
if (login!=null&&password!=null&&login.length()<=100){
// Uses a secure Random not a simple Random
SecureRandom random = SecureRandom.getInstance("SHA1PRNG");
// Salt generation 64 bits long
byte[] bSalt = new byte[8];
random.nextBytes(bSalt);
// Digest computation
byte[] bDigest = getHash(ITERATION_NUMBER,password,bSalt);
String sDigest = byteToBase64(bDigest);
String sSalt = byteToBase64(bSalt);

ps = con.prepareStatement("INSERT INTO CREDENTIAL (LOGIN, PASSWORD, SALT) VALUES (?,?,?)");
ps.setString(1,login);
ps.setString(2,sDigest);
ps.setString(3,sSalt);
ps.executeUpdate();
return true;
} else {
return false;
}
} finally {
close(ps);
}
}

/**
* From a password, a number of iterations and a salt,
* returns the corresponding digest
* @param iterationNb int The number of iterations of the algorithm
* @param password String The password to encrypt
* @param salt byte[] The salt
* @return byte[] The digested password
* @throws NoSuchAlgorithmException If the algorithm doesn't exist
*/
public byte[] getHash(int iterationNb, String password, byte[] salt) throws NoSuchAlgorithmException {
MessageDigest digest = MessageDigest.getInstance("SHA-1");
digest.reset();
digest.update(salt);
byte[] input = digest.digest(password.getBytes());
for (int i = 0; i < iterationNb; i++) {
digest.reset();
input = digest.digest(input);
}
return input;
}

public void creerTable(Connection con) throws SQLException{
Statement st = null;
try {
st = con.createStatement();
st.execute("CREATE TABLE CREDENTIAL (LOGIN VARCHAR(100) PRIMARY KEY, PASSWORD VARCHAR(32) NOT NULL, SALT VARCHAR(32) NOT NULL)");
} finally {
close(st);
}
}

/**
* Closes the current statement
* @param ps Statement
*/
public void close(Statement ps) {
if (ps!=null){
try {
ps.close();
} catch (SQLException ignore) {
}
}
}

/**
* Closes the current resultset
* @param ps Statement
*/
public void close(ResultSet rs) {
if (rs!=null){
try {
rs.close();
} catch (SQLException ignore) {
}
}
}

/**
* From a base 64 representation, returns the corresponding byte[]
* @param data String The base64 representation
* @return byte[]
* @throws IOException
*/
public static byte[] base64ToByte(String data) throws IOException {
BASE64Decoder decoder = new BASE64Decoder();
return decoder.decodeBuffer(data);
}

/**
* From a byte[] returns a base 64 representation
* @param data byte[]
* @return String
* @throws IOException
*/
public static String byteToBase64(byte[] data){
BASE64Encoder endecoder = new BASE64Encoder();
return endecoder.encode(data);
}

}

[[Category:OWASP Java Project]]

Hacking Java Clients

2008-01-14T12:56:56Z

Stephendv: /* Hacking Java Clients */

== Status ==
Released 14/1/2008

== Hacking Java Clients ==
When performing a security assessment of client-server Java applications, it is sometimes necessary to modify the client component in order to properly understand and assess the security mechanisms in place. Typical examples are systems that employ a communication channel that can't be intercepted with tools such as the personal proxies (WebScarab, Paros, etc.). A convenient means of accessing the internals of a Java program is to have an interactive scripting environment (BeanShell, Jython, JRuby, Groovy, etc.) that exposes the internal objects and allows you to perform arbitrary operations on these objects. The following [http://research.corsaire.com/whitepapers/060816-assessing-java-clients-with-the-beanshell.pdf white paper] outlines this technique.

There are a number of techniques that can be used to insert such an interpreter, these include:
# Recompile the source code and include the interpreter into the app. (Of course, you'll need access to the source and a build environment)
# Insert the interpreter using inheritance (as described in the white-paper mentioned above).
# Insert the interpreter by directly manipulating the byte-code
# Use [http://www.adaptj.com/root/main/stacktrace this tool]
# Use [http://www.fasterj.com/articles/hotpatch1.shtml a new feature implemented by Java 6]

[[Category:OWASP Java Project]]