Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]

---

S'abonner au fil RSS global de la revue de presse

---

Présentation : Following my recommending ESAPI post, there has been some great answers and comments on both SC-L and esapi-user list . Here is a great recent blog post on EASPI What is the ESAPI To help to clarify why I asked those questions and my chain of thought here are two extra entries with my personal opinion. The first one is a post that that I started writing a couple days ago, and the 2nd one, is a response I just posted on the SC-L and esapi-user mailing lists 1st one note that some of the questions asked here are already answered in some of the comments to the original post My position is that ESAPI is a great example of what an enterprise security API should look like. But we have to be very careful when we say 'use ESAPI', because we risk that people actually use ESAPI on their applications i.e. download the jar and copy it into their application, and use it I think we need to be careful to do this recommendation for several reasons. The first one is that when we say 'use EASPI', we are basically positioning ESAPI in competition with all the other frameworks including J2EE in this case, for the Java side of things . The second one is we have to provide much more visibility to the bits of ESAPI that are ready to be used in production. My understanding is that there are a lot of modules in ESAPI and not all of them have the same level or quality or readiness. Some of our target audience is going to be developers without a lot of experience in application security, but who want to implement their security controls features right, So we have to be very, very clear, whether we are providing them with the right advice on ESAPI, namely on which modules are actually enterprise-ready. for ex Is it just the encoding module or the logging module Or is the authentication module also ready for enterprise or application use For me, part of the solution is to explicitly break ESAPI into three parts. The first one is the interfaces. Basically, the security controls that an ESAPI API or ESAPI compliant framework should have. The second one should be a reference implementation s , which is what we have today and is the one that should be commercially supported by third parties . The third one, are unit tests for the interfaces. This is a bit where I'm actually quite interested, and I call these the ESTAPI, which is the Enterprise Security Testing API. I think that is a really valuable asset that we need to implement asap staring by extracting what is already inside the ESAPI implementations . With ESTAPI , we will have a particular set of tests for a particular 'security sensitive behaviour', for example ...If you are doing encoding for HTML, this is what you should do. If you are doing encoding for Javascript, this is what you should do. If you are doing encoding for HTML attributes, this is what you do. If you are doing encoding for exec inside a Javascript block...., if your are doing authentication...., if you are doing authorization, ... if you are implementing a password reset... ,..etc., etc. ... With the ESTAPI, I'll be able to run these tests against all supported frameworks, whereby for each framework, all I need are little connecters between the ESAPI interface and the particular framework functionality behaviour. Then we will be able to test the frameworks for their security capabilities. I think this will actually provide a much more pragmatic and much more objective analysis of the framework, allow the mapping of the supported security controls behaviour, and allow the framework's clients to have much more visibility into what's happening on those frameworks. Again, I don't want to put ESAPI down. I think ESAPI is a great project. I think it's one of the most successful and powerful projects for OWASP and we just need to clarify it a little bit. In fact, I think the more successful ESAPI is, the more this becomes a problem. I don't think ESAPI has blown up yet because ESAPI hasn't reached a wide level of adoption by software developers or commercial applications. Remember that one day we will have to deal with the problems of applications built on top of ESAPI that have security vulnerabilities or that are being successfully compromised by malicious hackers. 2nd one posted on on mailing lists My view is that the key to make this work is to create the ESTAPI, which is the Enterprise Security Testing API This way we would have for every language ESAPI Interfaces - which describe the functionality that each security control should have ESTAPI - Unit Tests that check the behaviour of the security controls ESAPI Reference Implementation s - Which are wherever possible 'production ready' versions of those security controls and in most cases a one-to-one mapping to the ESAPI Interfaces Framework XYZ ESAPI 'connectors' - Which wrap or expose the security controls defined in the ESAPI Interfaces in Framework XYZ What I really like about this world, is that we Application Security Consultants we start to create standards for how Security Controls should behave. and as important are able to work with the Framework developers without they felling that ESAPI is a 'competitor' to they Framework. After all, the way we will really change the market is when the Frameworks used by the majority of developers adopt ESAPI or its principles Of course that the Framework developers are more than welcomed to grab large parts or even all of the code provided by the ESAPI reference implementation s . But the key is that they the framework developers must a take ownership of the code and b respect the ESAPI Interfaces. And hey, if the Framework developers decide NOT to implement a particular security control, that is fine too. BUT I would at least expect them to provide detailed information why they made that decision and why they chose NOT to implement or support it which would allow us Security community to respectably agree or disagree with their choices hey for some Frameworks, being insecure is a feature Finally, In addition to all the advantages that we will have when frameworks adopt these security controls, there is one that for me is probably the MOST important one An 'ESAPI compliant app' which btw is a term we still have to agree what exactly means ,is an app that is providing explicit information about where they the developers think their the app security controls are located. In another works, via the ESAPI Interfaces and the ESTAPI tests the developers are actually telling us the security consultants a what they think their application's attack surface is and b what is the security behaviour that they have already tested for Of course that they can game the system, which is why we Security Consultants will still be needed we will also need to make sure that they implemented the security controls properly . But compare that to today's 2009 world, were we are lucky to get an up-to-date application diagram and a reasonable accurate description of how the application was actually coded and behaves. This would also finally give the application security tools white, black, glass, gray, pink, blue a fighting change to automatically, or operator-driven, understand what is going on and report back - what it knows security vulnerabilities and as important - what it doesn't know understand ok there is a lot more that these tools will provide us for example ESTAPI tests but that is a topic for another post So, for me, the key added value of the ESAPI Interfaces, is that it will provide us Security Consultants a way to understand how the app works from a security point of view and to be able to finally be able to give the clients what they want Visibility, Assurance and the ability to make 'knowledgeable Risk-based decisions'.

Les éléments de la revue Twitter pour les mots clé : esapi





Les derniers articles du site "Dinis Cruz blog" :

- Tool to view and unload the AppDomains in the current .Net Process

---

S'abonner au fil RSS global de la revue de presse

---