> Whereas most programmers compose things to ensure certain things > happen in certain cases, as appsec engineers, we need to ensure that > certain things do not happen in any case, and so our calculus is > roughly opposite that of the programmer, and we are in the difficult > position of proving universals (conventionally, "proving a negative"). > By removing abilities from software (i.e. "this source file does not > use eval"), we can reason much more reliably about their capabilities > and tailor our reviews to relevant sections. If there are no > constraints, we must review all of the code. Unfortunately I do > not see such constraints added in at the language level, but I have > not researched Java sandboxes and such yet.
I poked at the SecurityManager and Java sandboxes — the main problem is that if you have any kind of reflection or classloading ability at all, then you can poke into things very easily. https://tersesystems.com/2015/12/22/an-easy-way-to-secure-java-applications/ https://tersesystems.com/2015/12/29/sandbox-experiment/ The Google App Engine sandbox vulnerabilties in particular make a great read: http://www.security-explorations.com/en/SE-2014-02.html The interesting thing is that most attackers seem to be going for a single target: System.setSecurityManager(null). That’s a very unusual call, so if you can add a tripwire around it with Java instrumentation, you can find out an attacker immediately. Put up a blog post about it today: https://tersesystems.com/2016/01/19/redefining-java-dot-lang-dot-system/ > The problems which are most pernicious are those which do not operate > through a single, identifiable API, and so cannot be grepped for - > XSS, SQLi, integer vulns... are based on primitive operations mixing > tainted and untainted data, with many APIs (or implicit) for tainted data > sinks. Is there an execution environment equivalent of a context free grammar? “This statement cannot be executed in sandbox foo”? (I realize we’re starting to sound like GED here.) Will. _______________________________________________ langsec-discuss mailing list langsec-discuss@mail.langsec.org https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
