Burp Suite User Forum

Create new post

Expression Language Injection Syntax

Andy | Last updated: Dec 18, 2017 06:37PM UTC

I'm trying to improve my understanding of expression language (EL) injections. The following injections were created by Burp Scanner: ${@java.lang.Thread@sleep(500)} ${"aaaaaaaaaaaaaaaa".toString().replace("a","b")} Why are the at signs "@" needed to reference java classes and then their methods? I can't find anything online that references why the at sign there is correct syntax. JSP EL doesn't seem to use it and Spring EL only seems to use it for Bean references (?). An additional example I created is: ${@java.util.UUID@randomUUID()} Second but related question: Why don't either of these commands work? Is this due to permissions placed on certain methods and properties? Nothing is returned at all when these are attempted. ${@java.lang.Thread@toString()} ${@java.lang.Thread@getName()} Thanks! Andy

PortSwigger Agent | Last updated: Dec 21, 2017 03:09PM UTC

Hi Andy, Apologies for the delay in getting back to you. The developer of that particular test is out-of-office; we'll get back to you after the break.

PortSwigger Agent | Last updated: Jan 12, 2018 09:48AM UTC

Hi Andy, Apologies for not getting back to you. We're just wrapping up for the weekend, but I will look at your case next week.

Burp User | Last updated: Jan 19, 2018 04:16PM UTC

Hi again, still hoping to hear back from someone. I'd appreciate it, thanks! Andy

PortSwigger Agent | Last updated: Jan 19, 2018 04:18PM UTC

Hi Andy, Thanks for your patience. I've now discussed this with my colleagues. The second payload you mention - ${"aaaaaaaaaaaaaaaa".toString().replace("a","b")} - is very similar to what our Expression Language Injection check uses. However, the first payload is not familiar to people here, and we think it was generated by an extension. From a quick check of all the extensions for the string "@java" it could be ysoserial that is using the payload. The @java.lang.Thread@ syntax can appear when some Java objects are converted to strings. It's possible your app returns this value in output somewhere and Burp is noticing this and using it in a subsequent payload. So, in short the @ syntax is not a common attack and not something we'd usually try - so that you have got it to work on your app is really quite fortuitous! If you still have them, we'd be interested to see screenshots of this happening in Flow or Logger++.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.