all initial points of contact to your site should go thru a login process with a public key backed by a cert provided by vendor(you)
if the cert was self-signed or the key is forged you should return a 401 if the JSSE Key exchange is successful then yourm session will be assigned a secure token valid only for that Session and you will now exchange information on SSLv3/TLS Transport which ever connector is assigned to handle Secure Traffic The assigned Session-Token would "follow you" thru the system and if your tokens Principal was not in Role for the page or resource then client sees a 403ed (Forbidden) coming from you if ANYTHING does happen to your Session (invalidate or timeout) ...you invalidate the secure Token as well attempts to hack the Token by reading cookies wouldnt work either as each assigned Token is calc'ed off of JSESSION-ID by an algo than changes at random intervals SSLv3/TLS algos change on random intervals..so a cipher/algo worked for One session would not work the next session Both Encryption and Decryption Algorithms as well as their respective Salt length would change at random intervals If you are a Math whiz and you developed an algo SSL/TLS encrypt algo going up it would not work for the algo coming down ...Each entity's update schedule is orthogonal meaning that any entity cannot and should not necessarily be able to be derived from another known entity (by conventional means) Moreover since most crypto algos are migrating from symmetric (same algo for encryption and decryption) to asymetric (differing algos for encryption and decryption) the work you put into creating one non-repudiating algo for encrypting does not necessarily dovetail to crack'ing the second algo...http://en.wikipedia.org/wiki/Assymetric_key_cryptography the algos can be and are oftentimes different as seen here Browser->Algo1->Server vs Browser<-Algo2<--Server "how bad strust2 vulnerability is"... last time i checked this is not "strust2" list Regards, Martin ______________________________________________ > Date: Wed, 16 Oct 2013 08:21:28 -0400 > From: ere...@mail.nysed.gov > To: user@struts.apache.org > Subject: Re: Steps Involved in counter measurement for security issues > > First of all, security on web applications is of a concern but not as > much as one would think. > > To find all the security vulnerabilities within any application, or > framework, one would find all the entry points which allow user > provided data. This could be a field, a protocol, etc. and then one > would "fuzz" this process until the program crashed. > > Not only does a hacker need to crash the program, but hacking also > requires knowledge by the attacker of the underlying operating system > and what version it is. Most web applications run in a virtual > environment with proxies between the real server and the user, so just > finding out what to attack is hard if the network is properly > configured. > > Certainly something to consider but you will probably never find all > the vulnerabilities, it's a much better approach to monitor your > network, and know your underlying systems. > > Even though struts can be hacked, look at all those .jar files you > included and run on your server with high level permissions. Those too > can be full of exploits and most of those libs are just downloaded from > the net by amateur developers. > > Eric Reed > New York State Department of Education > > > > > > >>> Lukasz Lenart <lukaszlen...@apache.org> 10/16/2013 7:12 AM >>> > Ok, so the only option is got through each security bulletin and check > provided Proof-of-Concept if it affects your application. And DMI > isn't a problem if used wise. > > https://cwiki.apache.org/confluence/display/WW/Security+Bulletins > > 2013/10/16 Sreekanth S. Nair <sreekanth.n...@egovernments.org>: > > Thanks Lukazs, the problem i'm facing now is our product is so huge > to do a > > migration and running mainly on DMI. I'm unable to convince my top > > management about how bad strust2 vulnerability is (since i dont know > how to > > replicate the vulnerability). So I have no choice other than option > 2. > > > > -- > > Thanks & Regards > > Srikanth > > Software Developer > > -------------------------------- > > eGovernments Foundations > > www.egovernments.org > > Mob : 9980078913 > > -------------------------------- > > > > > > On Wed, Oct 16, 2013 at 4:22 PM, Umesh Awasthi > <umeshawas...@gmail.com>wrote: > > > >> I do not think that is possible. > >> You have 2 options > >> > >> 1. Upgrade you struts2 version. > >> 2. Go through security vulnerability and see what was there and > create test > >> cases to see what exactly is happening and fix them by checking > patches. > >> > >> But IMO, upgrading to latest version is much more flexible and less > time > >> consuming than going through each and every vulnerability and > applying > >> fixes for them. > >> > >> > >> On Wed, Oct 16, 2013 at 4:17 PM, Sreekanth S. Nair < > >> sreekanth.n...@egovernments.org> wrote: > >> > >> > Test Case to test the security vulnerability (major ones) in > >> > struts2-core-2.1.2. > >> > > >> > -- > >> > Thanks & Regards > >> > Srikanth > >> > Software Developer > >> > -------------------------------- > >> > eGovernments Foundations > >> > www.egovernments.org > >> > Mob : 9980078913 > >> > -------------------------------- > >> > > >> > > >> > On Wed, Oct 16, 2013 at 4:15 PM, Lukasz Lenart > <lukaszlen...@apache.org > >> > >wrote: > >> > > >> > > 2013/10/16 Sreekanth S. Nair <sreekanth.n...@egovernments.org>: > >> > > > One more doubt, does this security vulnerability is able to > bring > >> down > >> > > the > >> > > > server :-) ? If we authorize ourselves to apache, is it > possible for > >> > > struts > >> > > > team to give us test case to check the vulnerability? > >> > > > >> > > What you mean by that? What test case you refer to? > >> > > > >> > > > >> > > Regards > >> > > -- > >> > > Łukasz > >> > > + 48 606 323 122 http://www.lenart.org.pl/ > >> > > > >> > > > --------------------------------------------------------------------- > >> > > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > >> > > For additional commands, e-mail: user-h...@struts.apache.org > >> > > > >> > > > >> > > >> > >> > >> > >> -- > >> With Regards > >> Umesh Awasthi > >> http://www.travellingrants.com/ > >> > > --------------------------------------------------------------------- > 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 >
