Did they provide more information? I see no inherent issue with building a URL from a .env file. It's not really different than storing your secret keys and similar things in the .env. It's much better than storing it directly in the code. If someone has enough access to your server to get into your .env, you're pretty boned already.
If they can provide an example of what kind of risk the asset method and .env present, we can probably get it figured out. But if they're just going to make vague statements like "SECURITY RISK OMG!" I'm not sure what help they are, or what help we can be to them.
Hello Justin thx for the response, After asking some more i got a message related to the the problem being DNS injection, since the asset (I needed to dig deep)ends up getting the base URL via $servers['server_name'] (request()->getBaseUrl() or $this->getBaseUrl() in the Request:class) I still don't know if its that big of a security risk.
I'm still having a bit of trouble following what exactly they're having trouble with.
Having looked into it, I do see now that web requests don't load the URL from a file. Laravel is getting all parts of it from the
$_SERVER super global. However, when you're trying to get a URL to be displayed in the user's browser, it seems very appropriate to use the web address they say they're viewing.
I'm not sure how they're using the term "DNS injection" (it doesn't fit my understanding of what that term means), but unless you're using
asset() to just find a file you plan to actually do something with (call an unescaped
shell_exec on, perhaps...), I'm still not understanding what they're getting at.
Did they provide an example of code they feel is exploitable? I'm not, personally, convinced that this is a vulnerability by itself. You can use
asset() to cause a vulnerability, but you can do that with PHP, or an unsecured server room.
Sign in to participate in this thread!
We'd like to thank these amazing companies for supporting us