0

Is there a way to prevent a user from changing applicationContext-security.xml in the Spring Security framework so that he can not change the defined intercept-url of the application.

<intercept-url access="hasRole('ROLE_ADMIN')" pattern="/choices/**"/>
<intercept-url access="hasAnyRole('ROLE_SYSADMIN')" pattern="/departments/**"/>
<intercept-url access="hasAnyRole('ROLE_SYSADMIN')" pattern="/employees/**"/>
niks75
  • 73
  • 7
  • What do you mean? Users can't access the Spring context files themselves, it's the application which is doing this. – carlspring Mar 21 '13 at 10:36
  • I am trying to prevent a user from opening the war file and changing the intercept-urls in applicationContext-security.xml and then redeploying the application again. – niks75 Mar 21 '13 at 13:47
  • In that case, perhaps you should also obfuscate your code and add checks if any of the classes have changed as well...?! If they have the sources or decompile the code and manage to rebuild it, you'll still have the same problem. Therefore, if they alter the settings and make changes you do not approve of, simply tell them you won't support these settings. Simple as that. – carlspring Mar 21 '13 at 14:25
  • I am looking at AOT tools as an option instead. any suggestions? – niks75 Mar 26 '13 at 04:07
  • AOT or AOP? What is AOT? – carlspring Mar 26 '13 at 10:57
  • Yes its AOT only. http://en.wikipedia.org/wiki/AOT_compiler – niks75 Mar 28 '13 at 04:13
  • In my opinion you are trying to secure the wrong thing, if the user has access to the war most likely he also has access to the data you are trying to protect. If you don't trust the one managing your war files, I would opt for an auditing mechanism. For example you could write a testsuite which opens a connection to the web and tries to perform forbidden actions. You can then run this independently to review the security. – Nils Nov 11 '14 at 19:48

1 Answers1

0

I have not done this yet, but you can do it by signing your jar and verifying it programmatically at startup.

Verifying Jar Signature

By starting your application, you have to trigger the code that validates your JARfile and do something to fail the start if the signatures isnt available or manipulated.

See also: http://docs.oracle.com/javase/tutorial/deployment/jar/signindex.html

This will not prevent an "attacker" to unpack the jar, and modify the code and pack it without a signed manifest, but the effort would be much higher (according to your validation and prevention mechanism).

At least you can use yGuard to obfuscate and shrink your class-files.

Community
  • 1
  • 1
Martin Baumgartner
  • 3,524
  • 3
  • 20
  • 31
  • I am looking at AOT tools as an option instead. any suggestions? – niks75 Mar 26 '13 at 04:08
  • Do you mean AOP as Aspect Oriented Programming to replace your xml-files? I dont think there is support for aop-config in spring security, but you may take a look into the manual at http://static.springsource.org/spring-security/site/docs/3.2.x/reference/springsecurity-single.html – Martin Baumgartner Mar 27 '13 at 14:28
  • I meant (Ahead of Time) compilation. Sorry about that. http://en.wikipedia.org/wiki/AOT_compiler – niks75 Mar 28 '13 at 04:12