esapi-java-legacy
esapi-java-legacy copied to clipboard
ESAPI
Split ESAPI into Components
From chrisisbeef on November 20, 2010 16:13:38
Splitting ESAPI into manageable components to reduce the footprint and allow developers to customize their implementation to fit their specific needs.
Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=186
Yes. Haven't looked at the details of this, but this one probably should have the label of "Milestone 3.0" if it doesn't already. I.e., this issue the reason for the (now stalled) ESAPI/esapi-java repo. Maybe we should close close this issue here and open it there??? Thoughts?
-kevin
Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall NSA: All your crypto bit are belong to us.
On Jul 31, 2017 12:02 PM, "Matt Seil" [email protected] wrote:
@jeremiahjstacey https://github.com/jeremiahjstacey
This sounds like something you'd be interested in too.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ESAPI/esapi-java-legacy/issues/196#issuecomment-319115210, or mute the thread https://github.com/notifications/unsubscribe-auth/AB3nmxjovXbpqInIRQb2-smzQcSzy5Hkks5sTfqZgaJpZM4C6wqB .
This was one of the reasons I came to this project actually... just... so many other issues to clear up first!
@jeremiahjstacey actually had a version of this in a test branch. I've long since lost the email, but I recall he had successfully splitted all of the components.
Started down that path with https://github.com/jeremiahjstacey/esapi_reorg The intention was to break the current implementation into API and Lib artifacts. API would be restricted to interfaces and contracts that can be applied to a solution. Lib would be the default implementation of the api offered by the ESAPI library. Most of what's there is focused around validation. I started to play with codecs but didn't have much momentum with it.
It is hard to conceive how we can easily do this without 1) a drastic re-architecture and decoupling of ESAPI, and 2) such changes are likely to impact the ESAPI interfaces. Changing interfaces would break backward compatibility of applications using ESAPI 2.x, so I think this needs deferred to ESAPI 3.0, which were are not going to promise as backward compatible with ESAPI 2.x. Therefore marking this as milestone 3.0.
The biggest issue for us with ESAPI is that it has a boatload of dependencies. These dependencies get out of date and themselves get security issues reported against them. Its just too much when all you need is one of the utility methods that Veracode trusts.
Perhaps the project could start with componentization by breaking out the things that have no dependencies into their own core library. Things like static methods that people often need would then be available without all the extra cruft.
After a review, the packages org.owasp.esapi, org.owasp.esapi.util and org.owasp.esapi.errors could be extracted into a core package completely backwards compatible. Those three have only references to each other, the JDK, and the servlet-api, which can be included as a provided dependency.
Then start breaking things out by major dependency sets. Have a specific extension lib for SLF4J for instance. This should be backwards compatible. The biggest issue is supporting the module system. The module system requires that a given package be contained in just one jar. If there are multiple dependencies associated with a given package, then that's a point where you need to break compatibility and go to solve that issue in v3.
This is planned for ESAPI 3. It is not feasible for ESAPI 2.x and we will not be fixing it there; it simply is not worth the effort.
-kevin
Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall NSA: All your crypto bit are belong to us.
On Fri, Apr 3, 2020, 09:49 Avery Regier [email protected] wrote:
The biggest issue for us with ESAPI is that it has a boatload of dependencies. These dependencies get out of date and themselves get security issues reported against them. Its just too much when all you need is one of the utility methods that Veracode trusts.
Perhaps the project could start with componentization by breaking out the things that have no dependencies into their own core library. Things like static methods that people often need would then be available without all the extra cruft.
Then start breaking things out by major dependency sets. Have a specific extension lib for SLF4J for instance. This should be backwards compatible. The biggest issue is supporting the module system. The module system requires that a given package be contained in just one jar. If there are multiple dependencies associated with a given package, then that's a point where you need to break compatibility and go to solve that issue in v3.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ESAPI/esapi-java-legacy/issues/196#issuecomment-608443682, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAO6PGZMFVDNRBELA6MYBYTRKXSM5ANCNFSM4AXLBKAQ .
@AveryRegier - A longer answer, which I think you deserve. The biggest single problem is that ESAPI 1.x and 2.x were designed and packaged as a monolithic library of security controls. A decade or more ago, we talked about at least splitting out ESAPI into an ESAPI core and ESAPI reference implementation. The core would only contain the ESAPI interfaces and only the essential functionality (basically enough to more or less bootstrap the reference implementation. The 'core' would have very little dependencies, in fact not much more than what you describe. But we realized that if we packaged the 'reference implementation' part, it would pretty much have all the dependencies that the current ESAPI jar has, so that really wouldn't be a substantial win. So then we thought, well, we could split the reference implementation more granularly so would have separate reference implementation jars for each of the major components: one for the ESAPI Encoder, one for the ESAPI Validator, one for the ESAPI crypto, etc. The problem is that while most (we may have missed a few, but we could hunt those down and eliminate them) of the reference components used the ESAPI interfaces when they needed to access another component, in reality, there is way too much interdependencies on the components. For example, the DefaultSecurityConfiguration class in reality is used in every component so one automatically gets it plus any dependencies it requires. Everything also uses the ESAPI Logger so we would need an ESAPI-Logger dependency and since we defer the internal logging to what the requires, it would mean all those dependencies. Likewise the ESAPI Validator reference has dependencies on some of the ESAPI Encoder components (notably the Codecs). For that matter, even the ESAPI Logger has dependencies on the Codecs. So the bottom line, it gets pretty ugly the deeper you look. That is not to say that this is a non-solvable problem, but rather one that just doesn't be solving in ESAPI 2.x. (There are a lot of other major design issues with ESAPI 2.x that need addressed as well besides the large number of dependencies. For example, the fact that almost every component is implemented as a singleton pattern which causes massive headaches for some of the components. Also many of the interfaces for the various components are way too bloated.) So the plan is to fix some of the major esapi-java-legacy GitHub issues and then wide down and start work on ESAPI 3.0. But we do not intend on fixing this in ESAPI 2.x.
@xeno6696 and @jeremiahjstacey - I've already marked this for the '3.0' milestone, but I was wondering if I should just close this issue (since 2.x is as far as we plan on going for esapi-java-legacy) and marking it as 'wontfix'. What are your thoughts about that vs just leaving it open? I technically don't think that we even need to mention this GitHub issue for https://github.com/ESAPI/esapi-java since getting rid of the huge # of dependencies by making it more modular has always been the main design goal for that. (Plus, I think in the not too distant future should work on a high level design proposal for ESAPI 3.x where we would include the design goals and we surely would mention this there.)