OWASP ESAPI è ancora il metodo consigliato per proteggere le pagine JSP

L'ESAPI OWASP non è più considerato un fiore all'occhiello o addirittura un progetto attivo. Kevin Wall, il proprietario del progetto per l'implementazione Java, Se stesso nel 2014 ha ammesso che il progetto sta morendo e ha detto:

I’m not, because I can’t. I, for one, can see the writing on the wall. (Pun intended.) All of the allegations that are being made against ESAPI are spot-on:

· Only one minor point release in since July 2011.

· 164 open issues, including 4 marked Critical and 11 marked as High.

· Far too many dependencies, something that has never been addressed despite being promised for almost 3 years.

· Wiki page still in the old OWASP format.

· Minimal signs of life of for ESAPI 3.0 in GitHub and ESAPI 2.x for Java on Google Code. Zero signs of life for implementations in other programming languages. [Note: Discounting the SalesForce one as I’ve not kept track of it.]

· For ESAPI for Java, a boogered up architecture where everything is a singleton making some things such as mock-testing all but impossible. Less than 80% test code coverage, in part, because of that.

· Lack of any significant user documentation outside of the Javadoc and the ESAPI crypto documentation.

· Disappointing participation at the ESAPI Hackathon.

Un'altra descrizione di Kevin Wall su Devo usare ESAPI?

If you are starting out on a new project or trying for the first time to secure an existing project, then before you consider ESAPI, you should consider these possible alternatives:

• Output encoding: OWASP Java Encoder Project
• General HTML sanitization: OWASP Java HTML Sanitizer
• Validation: JSR-303/JSR-349 Bean Validation
• Strong cryptography: Keyczar
• Authentication / authorization: Apache Shiro
• CSRF protection: OWASP CSRFGuard Project or OWASP CSRFProtector Project

Note that this is not to suggest that ESAPI is dead, but rather to acknowledge the fact that it isn't being as well-maintained as most F500 companies would like for their enterprise software.

IMO se hai l'opzione che dovresti utilizzare framework come Spring, che ha le strutture per gestire molti problemi di sicurezza (ad es. Spring Security per l'autenticazione, CSRF). Per l'output, ancora molte strutture / librerie moderne si occupano della codifica. Per esempio. con JSP, quindi usa JSTL - ha una libreria di tag per la codifica HTML. Se stai sviluppando rich client, framework come React codificheranno in HTML per impostazione predefinita.

Uno scenario in cui ESAPI rimane utile è se si sta aggiornando un'applicazione legacy che non ha sicurezza. Anche allora, ESAPI ha abbastanza problemi aperti / vulnerabilità che dovrebbero darti una pausa. È un triste stato di cose e Kevin Wall si rivela un po 'amaro:

The first question to ask is, are you already using ESAPI in your project, and if so, do you have a lot vested in it? If so, then the answer to "Should I use ESAPI?" probably is "yes". The second question you should ask, if I'm using it, why am I not contributing to it in some manner? But we won't go there.