OWASP - User contributions [en]

File:Adam Boulton Security Assessing Java RMI - OWASP NYC.ppt

2009-04-09T07:27:26Z

Adam Boulton: Security Assessing Java RMI

Security Assessing Java RMI

User:Adam Boulton

2009-04-09T07:26:14Z

Adam Boulton:

== Summary ==

Adam Boulton is a Research Developer and Security Consultant for Corsaire. He has worked in IT Security since 2004, and has been programming since 2001. He graduated from Sheffield Hallam University in 2004 with a 1st Class BSc (Hons) Software Engineering Degree. 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.

== Specialties ==

Java Development, Assembly, Reverse Engineering, Networking, Computer Forensics, Penetration Testing, Source code reviews, Web application security assessments.

== LinkedIn Profile ==
[http://www.linkedin.com/profile?viewProfile=&key=12090735 Adam Boulton's LinkedIn Profile]

== Presentations ==

[[Media:Adam Boulton Security Assessing Java RMI - OWASP NYC.ppt]]

User:Adam Boulton

2009-04-09T07:25:16Z

Adam Boulton:

OWASP NYC AppSec 2008 Conference

2008-08-29T12:34:19Z

Adam Boulton:

= 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>
<br>
<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]<br>
<br>[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><br>
[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]
<br>
<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 <b>[http://www.pace.edu/page.cfm?doc_id=16157 Pace University]</b>, located in downtown New York City at <b>One Pace Plaza New York, NY 10038.</b> 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]
<br>
</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] <br>
''[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" | 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.

<b>[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]</b>

Java gotchas

2007-09-05T10:56:12Z

Adam Boulton: /* Immutable Objects / Wrapper Class Caching */

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

2007-08-31T09:38:39Z

Adam Boulton: /* Immutable Objects / Wrapper Class Caching */

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

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.

Java gotchas

2007-08-30T14:57:11Z

Adam Boulton: /* Boolean Assignment */

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

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.

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.

Java gotchas

2007-08-23T15:10:04Z

Adam Boulton: /* Boolean Assignment */

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

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.

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.

Java gotchas

2007-08-23T15:06:15Z

Adam Boulton: /* Boolean Assignment */

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

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.

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

Java gotchas

2007-08-23T15:05:46Z

Adam Boulton: /* Garbage Collection */

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

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.

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

Java gotchas

2007-08-23T14:42:21Z

Adam Boulton: /* Immutable Objects / Wrapper Class Caching */

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

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.

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.

Java gotchas

2007-08-23T14:41:47Z

Adam Boulton: /* Garbage Collection */

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

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.

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.

Java gotchas

2007-08-23T14:38:31Z

Adam Boulton: /* Garbage Collection */

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

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.

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.

Java gotchas

2007-08-23T14:36:18Z

Adam Boulton: /* Incrementing values */

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

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.

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.

Java gotchas

2007-08-09T11:34:36Z

Adam Boulton: /* Immutable Objects / Wrapper Class Caching */

Java gotchas

2007-08-09T11:30:34Z

Adam Boulton: /* Wrapper Class Caching */

Cross-Site Request Forgery (CSRF)

2007-07-08T19:12:44Z

Adam Boulton: /* Related Countermeasures */

{{Template:Attack}}

==Description==

Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks target functions that cause a state change on the server.

For most sites, such a request will normally automatically include any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user has authenticated to the site, the site will have no way to distinguish this from a legitimate user request.

In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, or any other function provided by the vulnerable website.

If it is possible to store the CSRF attack on the vulnerable site itself, by means such as cross-site scripting then the severity of the attack is amplified. The likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood of a successful attack is also increased because the victim is sure to be authenticated to the site already.

Synonyms: CSRF attacks are also known by a number of other names, including XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.

==How does the attack work?==

There are numerous ways in which an end-user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using bank.com. The request generated by Alice will look similar to the following:

POST <nowiki>http://bank.com/transfer.do</nowiki> HTTP/1.1
...
...
...
Content-Length: 19;

acct=BOB&amount=100

However, Maria notices that the same web application will execute the same transfer using URL parameters as follows:

GET <nowiki>http://bank.com/transfer.do?acct=BOB&amount=100</nowiki> HTTP/1.1

Maria now decides to exploit this web application vulnerability using Alice as her victim. Maria first constructs the following URL which will transfer $100,000 from Alice's account to her account:

<nowiki>http://bank.com/transfer.do?acct=MARIA&amount=100000</nowiki>

Now that her malicious request is generated, Maria must trick Alice into submitting the request. The most basic method is to send Alice an HTML email containing the following:

<nowiki><a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a></nowiki>

Assuming Alice is authenticated with the application when she clicks the link, the transfer of $100,000 to Maria's account will occur. However, Maria realizes that if Alice clicks the link, then Alice will notice that a transfer has occurred. Therefore, Maria decides to hide the attack in a zero-byte image:

<nowiki><img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="1" height="1" border="0"></nowiki>

If this image tag were included in the email, Alice would only see a little box indicating that the browser could not render the image. However, the browser ''will still'' submit the request to bank.com without any visual indication that the transfer has taken place.

==Prevention measures that do '''NOT''' work==

;Using a secret cookie
:Remember that all cookies, even the ''secret'' ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

;Only accepting POST requests
:Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request. The two most common methods are through the use of phishing sites (sites which appear to look like another valid site) and through the use of XMLHTTPRequest in a Cross-Site Scripting attack.

==Related Threats==

==Related Attacks==

[[XSS]]

==Related Vulnerabilities==

==Related Countermeasures==

* Add a per-request nonce to URL and all forms in addition to the standard session. This is also referred to as "form keys". Many frameworks (ex, Drupal.org 4.7.4+) either have or are starting to include this type of protection "built-in" to every form so the programmer does not need to code this protection manually.
* TBD: Add a per-session nonce to URL and all forms
* TBD: Add a hash(session id, function name, server-side secret) to URL and all forms
* TBD: .NET - add session identifier to ViewState with MAC
* Checking HTTP referrer details can help mitigate the attack but does certainly not provide a bullet proof solution. By ensuring the HTTP posts have come from the original site means that the attacks from other sites will not function. However, if the CSRF attack was used in combination with XSS on the original site then this mechanism will not provide any protection.
* "Although cross-site request forgery is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser's cookies at the end of each browser session." -http://en.wikipedia.org/wiki/Cross-site_request_forgery#_note-1

==References==
; [http://www.cgisecurity.com/articles/csrf-faq.shtml The Cross-Site Request Forgery (CSRF/XSRF) FAQ]
: ''quote: "This paper serves as a living document for Cross-Site Request Forgery issues. This document will serve as a repository of information from existing papers, talks, and mailing list postings and will be updated as new information is discovered."''

; [[Testing for CSRF]]
: CSRF (aka Session riding) paper from the OWASP Testing Guide project (need to integrate)

; [http://www.darkreading.com/document.asp?doc_id=107651&WT.svl=news1_2 CSRF Vulnerability: A 'Sleeping Giant']
: Overview Paper

; [http://www.owasp.org/index.php/Image:OWASPAppSecEU2006_RequestRodeo.ppt RequestRodeo: Client Side Protection against Session Riding]
: Martin Johns and Justus Winter's interesting paper and presentation for the 4th OWASP AppSec Conference which described potential techniques that browsers could adopt to automatically provide CSRF protection - [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf PDF paper]

; [http://www.owasp.org/index.php/CSRF_Guard CSRF Guard]
: A J2EE Filter which appends a unique request token to each form and link in the HTML response

[[Category:Attack]]

Cross-Site Request Forgery (CSRF)

2007-07-08T19:00:05Z

Adam Boulton: /* Description */

{{Template:Attack}}

==Description==

Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks target functions that cause a state change on the server.

For most sites, such a request will normally automatically include any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user has authenticated to the site, the site will have no way to distinguish this from a legitimate user request.

In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, or any other function provided by the vulnerable website.

If it is possible to store the CSRF attack on the vulnerable site itself, by means such as cross-site scripting then the severity of the attack is amplified. The likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood of a successful attack is also increased because the victim is sure to be authenticated to the site already.

Synonyms: CSRF attacks are also known by a number of other names, including XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.

==How does the attack work?==

There are numerous ways in which an end-user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using bank.com. The request generated by Alice will look similar to the following:

POST <nowiki>http://bank.com/transfer.do</nowiki> HTTP/1.1
...
...
...
Content-Length: 19;

acct=BOB&amount=100

However, Maria notices that the same web application will execute the same transfer using URL parameters as follows:

GET <nowiki>http://bank.com/transfer.do?acct=BOB&amount=100</nowiki> HTTP/1.1

Maria now decides to exploit this web application vulnerability using Alice as her victim. Maria first constructs the following URL which will transfer $100,000 from Alice's account to her account:

<nowiki>http://bank.com/transfer.do?acct=MARIA&amount=100000</nowiki>

Now that her malicious request is generated, Maria must trick Alice into submitting the request. The most basic method is to send Alice an HTML email containing the following:

<nowiki><a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a></nowiki>

Assuming Alice is authenticated with the application when she clicks the link, the transfer of $100,000 to Maria's account will occur. However, Maria realizes that if Alice clicks the link, then Alice will notice that a transfer has occurred. Therefore, Maria decides to hide the attack in a zero-byte image:

<nowiki><img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="1" height="1" border="0"></nowiki>

If this image tag were included in the email, Alice would only see a little box indicating that the browser could not render the image. However, the browser ''will still'' submit the request to bank.com without any visual indication that the transfer has taken place.

==Prevention measures that do '''NOT''' work==

;Using a secret cookie
:Remember that all cookies, even the ''secret'' ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

;Only accepting POST requests
:Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request. The two most common methods are through the use of phishing sites (sites which appear to look like another valid site) and through the use of XMLHTTPRequest in a Cross-Site Scripting attack.

==Related Threats==

==Related Attacks==

[[XSS]]

==Related Vulnerabilities==

==Related Countermeasures==

* Add a per-request nonce to URL and all forms in addition to the standard session. This is also referred to as "form keys". Many frameworks (ex, Drupal.org 4.7.4+) either have or are starting to include this type of protection "built-in" to every form so the programmer does not need to code this protection manually.
* TBD: Add a per-session nonce to URL and all forms
* TBD: Add a hash(session id, function name, server-side secret) to URL and all forms
* TBD: .NET - add session identifier to ViewState with MAC
* "Although cross-site request forgery is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser's cookies at the end of each browser session." -http://en.wikipedia.org/wiki/Cross-site_request_forgery#_note-1

==References==
; [http://www.cgisecurity.com/articles/csrf-faq.shtml The Cross-Site Request Forgery (CSRF/XSRF) FAQ]
: ''quote: "This paper serves as a living document for Cross-Site Request Forgery issues. This document will serve as a repository of information from existing papers, talks, and mailing list postings and will be updated as new information is discovered."''

; [[Testing for CSRF]]
: CSRF (aka Session riding) paper from the OWASP Testing Guide project (need to integrate)

; [http://www.darkreading.com/document.asp?doc_id=107651&WT.svl=news1_2 CSRF Vulnerability: A 'Sleeping Giant']
: Overview Paper

; [http://www.owasp.org/index.php/Image:OWASPAppSecEU2006_RequestRodeo.ppt RequestRodeo: Client Side Protection against Session Riding]
: Martin Johns and Justus Winter's interesting paper and presentation for the 4th OWASP AppSec Conference which described potential techniques that browsers could adopt to automatically provide CSRF protection - [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf PDF paper]

; [http://www.owasp.org/index.php/CSRF_Guard CSRF Guard]
: A J2EE Filter which appends a unique request token to each form and link in the HTML response

[[Category:Attack]]

Cross-Site Request Forgery (CSRF)

2007-07-08T18:58:37Z

Adam Boulton: /* Description */

{{Template:Attack}}

==Description==

Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks target functions that cause a state change on the server.

For most sites, such a request will normally automatically include any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user has authenticated to the site, the site will have no way to distinguish this from a legitimate user request.

In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, or any other function provided by the vulnerable website.

If it is possible to store the CSRF attack on the vulnerable site itself, by means such as cross-site scripting then the severity of the attack is amplified. The likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood of a successful attack is also increased because the victim is sure to be authenticated to the site already.

Synonyms: CSRF attacks are also known by a number of other names, including XSRF, Session Riding, Cross-Site Reference Forgery, and Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.

==How does the attack work?==

There are numerous ways in which an end-user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using bank.com. The request generated by Alice will look similar to the following:

POST <nowiki>http://bank.com/transfer.do</nowiki> HTTP/1.1
...
...
...
Content-Length: 19;

acct=BOB&amount=100

However, Maria notices that the same web application will execute the same transfer using URL parameters as follows:

GET <nowiki>http://bank.com/transfer.do?acct=BOB&amount=100</nowiki> HTTP/1.1

Maria now decides to exploit this web application vulnerability using Alice as her victim. Maria first constructs the following URL which will transfer $100,000 from Alice's account to her account:

<nowiki>http://bank.com/transfer.do?acct=MARIA&amount=100000</nowiki>

Now that her malicious request is generated, Maria must trick Alice into submitting the request. The most basic method is to send Alice an HTML email containing the following:

<nowiki><a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a></nowiki>

Assuming Alice is authenticated with the application when she clicks the link, the transfer of $100,000 to Maria's account will occur. However, Maria realizes that if Alice clicks the link, then Alice will notice that a transfer has occurred. Therefore, Maria decides to hide the attack in a zero-byte image:

<nowiki><img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="1" height="1" border="0"></nowiki>

If this image tag were included in the email, Alice would only see a little box indicating that the browser could not render the image. However, the browser ''will still'' submit the request to bank.com without any visual indication that the transfer has taken place.

==Prevention measures that do '''NOT''' work==

;Using a secret cookie
:Remember that all cookies, even the ''secret'' ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

;Only accepting POST requests
:Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request. The two most common methods are through the use of phishing sites (sites which appear to look like another valid site) and through the use of XMLHTTPRequest in a Cross-Site Scripting attack.

==Related Threats==

==Related Attacks==

[[XSS]]

==Related Vulnerabilities==

==Related Countermeasures==

* Add a per-request nonce to URL and all forms in addition to the standard session. This is also referred to as "form keys". Many frameworks (ex, Drupal.org 4.7.4+) either have or are starting to include this type of protection "built-in" to every form so the programmer does not need to code this protection manually.
* TBD: Add a per-session nonce to URL and all forms
* TBD: Add a hash(session id, function name, server-side secret) to URL and all forms
* TBD: .NET - add session identifier to ViewState with MAC
* "Although cross-site request forgery is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser's cookies at the end of each browser session." -http://en.wikipedia.org/wiki/Cross-site_request_forgery#_note-1

==References==
; [http://www.cgisecurity.com/articles/csrf-faq.shtml The Cross-Site Request Forgery (CSRF/XSRF) FAQ]
: ''quote: "This paper serves as a living document for Cross-Site Request Forgery issues. This document will serve as a repository of information from existing papers, talks, and mailing list postings and will be updated as new information is discovered."''

; [[Testing for CSRF]]
: CSRF (aka Session riding) paper from the OWASP Testing Guide project (need to integrate)

; [http://www.darkreading.com/document.asp?doc_id=107651&WT.svl=news1_2 CSRF Vulnerability: A 'Sleeping Giant']
: Overview Paper

; [http://www.owasp.org/index.php/Image:OWASPAppSecEU2006_RequestRodeo.ppt RequestRodeo: Client Side Protection against Session Riding]
: Martin Johns and Justus Winter's interesting paper and presentation for the 4th OWASP AppSec Conference which described potential techniques that browsers could adopt to automatically provide CSRF protection - [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf PDF paper]

; [http://www.owasp.org/index.php/CSRF_Guard CSRF Guard]
: A J2EE Filter which appends a unique request token to each form and link in the HTML response

[[Category:Attack]]

OWASP Code Review Guide Table of Contents

2007-07-07T10:50:20Z

Adam Boulton: /* Examples by Vulnerability */

__NOTOC__

[[Chapters Assigned|Chapters Assigned]]
==[[Code Review Guide Foreword|Foreword by OWASP Chair]]==

==[[Code Review Guide Frontispiece |1. Frontispiece]]==

'''[[Code Review Guide Frontispiece|1.1 About the OWASP Code Review Project]]'''

Copyright

Editors

Authors and Reviewers

Revision History

Trademarks

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''

Overview

Structure

Licensing

Participation and Membership

Projects

OWASP Privacy Policy

==Guide History==
[[Long long ago...]]

==Methodology==

#[[Code Review Introduction|Introduction]]
#[[Steps and Roles]]
#[[Code Review Processes]]
#[[Transaction Analysis]]
[[Category:OWASP Code Review Project]]

==Crawling Code==
#[[Introduction]]
#[[First sweep of the code base]]
#[[Getting dug in]]

== Design review ==
#[[Designing for security]]
##[[.NET]]
##[[Java]]
##[[PHP]]
##[[C]]
##[[C++]]
##[[MySQL]]
##[[AJAX]]

==Examples by Vulnerability==
#[[Reviewing Code for Buffer Overruns and Overflows]]
#[[Reviewing Code for OS Injection]]
#[[Reviewing Code for SQL Injection]]
#[[Reviewing Code for Data Validation]]
#[[Reviewing code for XSS issues]]
#[[Reviewing code for Cross-Site Request Forgery issues]]
#[[Reviewing Code for Error Handling]]
#[[Reviewing Code for Logging Issues]]
#[[Reviewing The Secure Code Environment]]
#[[Reviewing Code for Authorization Issues]]
#[[Reviewing Code for Authentication]]
#[[Reviewing Code for Session Integrity issues]]
#[[Reviewing Cryptographic Code]]
#[[Reviewing Code deployment: Dangerous HTTP Methods]]
#[[Reviewing Code for Race Conditions]]

== Language specific best practice ==

===Java===
#[[Java overview]]
#[[Java gotchas]]
#[[Java applet code review]]
#[[Java server (J2EE) code review]]

===.NET===

===PHP===

===C===
#[[Memory management]]
#[[String management]]
#[[Secure access to file system items]]

===RUBY===

==[[Automating Code Reviews]]==
#[[Preface ]]
#[[Reasons for using automated tools]]
#[[Education and cultural change]]
#[[Tool Deployment Model]]
#[[Code Auditor Workbench Tool]]

==[[References]]==

[[Category:OWASP Code Review Project]]

Searching for Code in J2EE/Java

2007-07-07T09:25:38Z

Adam Boulton: /* SQL & Database */

== Searching for key indicators ==
The basis of the code review is to locate and analyse areas of code which may have application security implications.
Assuming the code reviewer has a thorough understanding of the code, what it is intended to do and the context upon which it is to be used, firstly one needs to sweep the code base for areas of interest.

This can be done by performing a text search on the code base looking for keywords relating to API's and functions.
Below is a guide for .NET framework 1.1 & 2.0

=== Searching for code in .NET ===

Firstly one needs to be familiar with the tools one can use in order to perform text searching following on from this one need to know what to look for.

In this section we will assume you have a copy of Visual Studio (VS) .NET at hand. VS has two types of search "'''Find in Files'''" and a cmd line tool called '''Findstr'''

The test search tools in XP is not great in my experience and if one has to use this make sure SP2 in installed as it works better.
To start off one should scan thorough the code looking for common patterns or keywords such as "User", "Password", "Pswd", "Key", "Http", etc...
This can be done using the "Find in Files" tool in VS or using findstring as follows:

[Find In Files HERE]

'''findstr /s /m /i /d:c:\projects\codebase\sec "http" *.*'''

====Http Request Strings====
Requests from external sources are onviously a key area of a secure code review. We need to ensure that all HTTP requests received are datavalidated for composition, max and min length and if the data falls with the relms of the parameter whitelist.
Bottom-line is this is a key area to look at and ensure security is enabled.

request.querystring
request.form
request.cookies
request.certificate
request.servervariables
request.IsSecureConnection
request.TotalBytes
request.BinaryRead

====HTML Output====
Here we are looking for responses to the client. Responses which go unvalidated or which echo external input without data validation are key areas to examine. Many client side attacks result from poor response validation. XSS relies on this somewhat.

response.write
<% =
HttpUtility
HtmlEncode
UrlEncode
innerText
innerHTML

====SQL & Database====
Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determine if the application is vulnerable to SQL injection. One aspect of this is to verify that the code uses either ''SqlParameter'', ''OleDbParameter'', or ''OdbcParameter''(System.Data.SqlClient). These are typed and treats parameters as the literal value and not executable code in the database.

exec sp_executesql
execute sp_executesql
select from
Insert
update
delete from where
delete
exec sp_
execute sp_
exec xp_
execute sp_
exec @
execute @
executestatement
executeSQL
setfilter
executeQuery
GetQueryResultInXML
adodb
sqloledb
sql server
driver
Server.CreateObject
.Provider
.Open
ADODB.recordset
New OleDbConnection
ExecuteReader
DataSource
SqlCommand
Microsoft.Jet
SqlDataReader
ExecuteReader
GetString
SqlDataAdapter
CommandType
StoredProcedure
System.Data.sql

====Cookies====
Cookie manipulation can be key to various application security exploits such as session hijacking/fixation and parameter manipulation. One should examine any code relating to cookie functionality as this would have a bearing on session security.
System.Net.Cookie
HttpOnly
document.cookie

==== HTML Tags====
Many of the HTML tags below can be used for client side attacks such as cross site scritping. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display and use of such tags withing a web application.

HtmlEncode
URLEncode
<applet>
<frameset>
<embed>
<frame>
<html>
<iframe>
<img>
<style>
<layer>
<ilayer>
<meta>
<object>
<body>
<frame security
<iframe security

====Input Controls====
The input controls below are server classes used to produce and display web application form fields. Looking for such references helps locate entry points into the application.

system.web.ui.htmlcontrols.htmlinputhidden
system.web.ui.webcontrols.textbox
system.web.ui.webcontrols.listbox
system.web.ui.webcontrols.checkboxlist
system.web.ui.webcontrols.dropdownlist

====web.config====
The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application’s root directory. For ASP.NET applications, web.config contains information about most aspects of the application’s operation.

requestEncoding
responseEncoding
trace
authorization
CustomErrors
httpRuntime
maxRequestLength
debug
forms protection
appSettings
ConfigurationSettings
authentication mode
allow
deny
credentials
identity impersonate
timeout

====global.asax====
Each application has its own Global.asax if one is required. Global.asax sets the event code and values for an application using scripts. One must ensure that application variables do not contain sensitive information, as they are accessible to the whole application and to all users within it.

Application_OnAuthenticateRequest
Application_OnAuthorizeRequest
Session_OnStart
Session_OnEnd

====logging====
Logging can be a source of information leakage. It is important to examing all calls to the logging subsystem and to determine if any sensitive information is being logged. Common mistakes are logging userID in conjunction with passwords within the authentication functionality or logging database requests which may contains sensitive data.

log4net
Console.WriteLine
System.Diagnostics.Debug
System.Diagnostics.Trace

====Machine.config====
Its important that many variables in machine.config can be overridden in the web.config file for a particular application.
validateRequest
enableViewState
enableViewStateMac

====Threads and Concurrancy====
Thread
Dispose

====Class Design====
Public
Sealed

====Reflection, Serialization====
ISerializable
AllowPartiallyTrustedCallersAttribute
GetObjectData
StrongNameIdentityPermission
StrongNameIdentity

====Exceptions & Errors====
catch{
Finally
trace enabled
customErrors mode

====Crypto====
base64
xor
DES
RC2
System.Random
Random

====Storage====
SecureString
ProtectedMemory

====Authorization, Assert & Revert====
.RequestMinimum
.RequestOptional
Assert
Debug.Assert
CodeAccessPermission
ReflectionPermission.MemberAccess
SecurityPermission.ControlAppDomain
SecurityPermission.UnmanagedCode
SecurityPermission.SkipVerification
SecurityPermission.ControlEvidence
SecurityPermission.SerializationFormatter
SecurityPermission.ControlPrincipal
SecurityPermission.ControlDomainPolicy
SecurityPermission.ControlPolicy

====Leagcy methods====
printf
strcpy

=== Searching for code in J2EE/Java ===

====Input Streams====
Java.io
FileInputStream
ObjectInputStream
FilterInputStream
PipedInputStream
SequenceInputStream
StringBufferInputStream
BufferedReader
ByteArrayInputStream
CharArrayReader
File
ObjectInputStream
PipedInputStream
StreamTokenizer
getResourceAsStream

====Servlets====
javax.servlet.
getParameterNames
getParameterValues
getAttribute
getAttributeNames
isSecure
HttpServletRequest
getQueryString
getHeader
getPrincipal
isUserInRole
getOutputStream
getWriter
addCookie
addHeader
setHeader

====SQL & Database====
Searching for Java Database related code this list should help you pinpoint classes/methods which are involved in the persistance layer of the application being reviewed.
jdbc
executeQuery
select
insert
update
delete
execute
executestatement
====SSL====
com.sun.net.ssl
SSLContext
SSLSocketFactory
TrustManagerFactory
HttpsURLConnection
KeyManagerFactory

====Session Management====
getSession
invalidate
getId

====Data Validation====

====Legacy Interaction====

====Crypto====

====Security Manager====

====System====

====Logging====

Java gotchas

2007-06-25T17:16:43Z

Adam Boulton: /* Integer Caching */

Java gotchas

2007-06-25T14:28:35Z

Adam Boulton: /* Incrementing values */

Java gotchas

2007-06-25T14:19:02Z

Adam Boulton: /* Equality */

Java gotchas

2007-06-25T07:11:44Z

Adam Boulton: /* Integer Caching */

User:Adam Boulton

2007-06-23T16:16:14Z

Adam Boulton: /* LinkedIn Profile */

User:Adam Boulton

2007-06-23T16:05:53Z

Adam Boulton: /* Summary */

== Summary ==

Adam Boulton is a Research Developer and Security Consultant for Corsaire. He has worked in IT Security since 2004, and has been programming since 2001. He graduated from Sheffield Hallam University in 2004 with a 1st Class BSc (Hons) Software Engineering Degree. 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.

== Specialties ==

Java Development, Assembly, Reverse Engineering, Networking, Computer Forensics, Penetration Testing, Source code reviews, Web application security assessments.

== LinkedIn Profile ==
http://www.linkedin.com/profile?viewProfile=&key=12090735

User:Adam Boulton

2007-06-23T15:45:13Z

Adam Boulton: New page: == Summary == Adam Boulton is a Research Developer and Security Consultant for Corsaire. He has worked in IT Security since 2004, and has been programming since 2001. He graduated from Sh...

== Summary ==

Adam Boulton is a Research Developer and Security Consultant for Corsaire. He has worked in IT Security since 2004, and has been programming since 2001. He graduated from Sheffield Hallam University with a 1st Class BSc (Hons) Software Engineering Degree. 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.

== Specialties ==

Java Development, Assembly, Reverse Engineering, Networking, Computer Forensics, Penetration Testing, Source code reviews, Web application security assessments.

== LinkedIn Profile ==
http://www.linkedin.com/profile?viewProfile=&key=12090735