Security has, and should be an open arrangement between developers and the clients for which they develop code.
This relationship is as follows: 1. I detect an exploit in YOUR code. 2. I inform you of the exploit along with a proof of concept. 3. I give you time to release a patch and notify your clients. (Around 2 months, give or take) 4. You fix the exploit. 5. Everyone is happy. If for some reason #4 is not done in time, I release the exploit along with my proof of concept, and it ends up as a BT module for the kiddies. This is the best relationship we have come up with so as to force developers to fix exploitable code, and maintain awareness. All this is on the net and each exploit is identified with a CVE number. For instance to see the security issues with Struts 2: http://struts.apache.org/release/2.3.x/docs/security-bulletins.html Then one can "google" CVE number for more details. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4316 Because of all the kiddies most sites will not show a proof of concept, but just keep on googling and you will find it. https://communities.coverity.com/blogs/security/2013/05/29/struts2-remote-code-execution-via-ognl-injection Try and re-produce the exploit in your project. For some reason if you have a large legacy application which cannot be upgraded without a total re-write, do what I have done for some Struts 1 apps and download the code and come up with a custom solution that works best for you. Even if you solution causes other security exploits, those exploits will not be known by anyone else so you should for the most part be ok, or at least a little better off than before. Security is a hard concept because it is always an after thought. (See Microsoft's OS from 1992 - present for clear examples) Regards, Eric >>> Manuel López Blasi<lopezbl...@conicet.gov.ar> 1/29/2014 4:28 PM >>> Thanks again Lukasz, for question 1) Security issues: can you recommend some modifications/actions/alterations in maybe certain parts of the code, any advice on weak points we can focus in regardings security issues? for question 2)Prepare interceptor: So there's no way of remove the "prepare" prefix? Maybe other implementation of that Interceptor? At this point my intention is to make a compromise between security and usability. Right now we are exposed cause we're using and old version of the framework but on the other hand the refactor required to comply with the last version it's just too much. I'm aiming at use the last version 2.3.16 with action.prefix enabled and try to add security elements in our code in the hope of preventing attacks. I know certain data can't be shared though this mailing list as it would expose vulnerabilities, maybe we can talk through other chanel, personal email maybe? It would really help us if you could tell me some guidelines. Your help would be greatly appreciated. Thanks again for everything, cheerz. El 29/01/2014 17:18, Lukasz Lenart escribió: > 2014-01-29 Manuel López Blasi <lopezbl...@conicet.gov.ar>: >> 1) Having the action.prefix enabled there's no intereference in the >> securyity fixes introduced in the last versions, it should be all fully >> working isn't it? >> We have Dynamic Method Invocation disabled. > No, action: prefix can be dangerous but it depends on security model > implemented inside actions and application. I cannot share more on > public mailing list to not disclose security vulnerability. > >> 2) Whe a button is clicked so it fires the method specified en the action >> attribute of the s:submit tag it seems that it looks for the method >> "prepareMethod" where Method is the method i specified, it seems that the >> prefix "prepare" is appended. Is there a way to override or disable this >> appending? >> Same goes for the method validate, it is looking for "prepareValidate" , i >> need to get rid of those appendings, since otherwise we would need to make a >> huge refactor of >> method namings in the project. > It is because of prepare interceptor which is included in stack you > are using. Basically prepareXXX is called to prepare action for > execution of desired method. > > http://struts.apache.org/release/2.3.x/docs/prepare-interceptor.html > > > Regards --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
