Level 102
Curious why you let users run cli commands on your server in the first place? That in itself seems like a really really bad idea!
Maybe if we understand what the actual need is we can give better advice
4 likes
Aug 29, 2024
16
Level 1
Security Concern: Exposure of .env File via API
We are facing a serious security issue with our backend infrastructure. We have API endpoints that allow command execution or access to the server's CLI.
Let me explain the scenario: Suppose our backend team creates an API for command execution on our server. This API could potentially expose the .env file of our project by running commands on the server. As we all know, the .env file contains crucial data that should only be accessible to IT admins and DevOps.
This issue poses a significant risk to our production environment, and any advice on how to secure it would be greatly appreciated. This is a serious vulnerability as it could expose sensitive server configuration details.
I found a possible solution: Disabling functions like exec, shell_exec, system, passthru, popen, and proc_open, which are used to gain CLI access in the LAMP stack server.
However, many of our APIs and services rely on the server's CLI. Disabling these functions in PHP could create significant issues for our server.
Please suggest How to secure the .env file access through the api ?
Thank you in advance for your help.
Level 1
@Sinnbeck this api is not for user ! suppose backend team using this api to run artisan commandn onto the server , if this api capable to run artissan command then it also run cat command so backend team can run cat /var/www/html/.env to get the .env file
Level 102
@hritikoptiumbrew Then only let them run artisan commands. Add a simple whitelist of available artisan commands that can be called. So if they call "do:stuff", your code runs Artisan::call('do:stuff'). No cli calls done at all
And if they try running a command that does not exist or isn't whitelisted, they get an error
1 like
Level 104
This is a serious vulnerability
No shit.
Allowing execution of any arbitrary command (even artisan commands) by end users is reckless; you need to find an alternative implementation or abandon this service.
2 likes
Level 1
@tykus I need to explain my concern: Suppose the backend team is trying to access the .env file through an API. Since we are all using a CI/CD pipeline, we are not always fully aware of the changes made by the backend team. Suppose they create an API that can interact through the CLI and access the .env file. I want a solution that will secure the .env file from being accessed through an API.
Level 1
@Sinnbeck I need to explain my concern: Suppose the backend team is trying to access the .env file through an API. Since we are all using a CI/CD pipeline, we are not always fully aware of the changes made by the backend team. Suppose they create an API that can interact through the CLI and access the .env file. I want a solution that will secure the .env file from being accessed through an API
Level 80
@hritikoptiumbrew Why on earth are users able to run commands on your server via API requests in the first place?
Yes, if you give users the ability to execute arbitrary commands on your server then there’s the potentially they’ll run nefarious commands. You may as well just give them an SSH key and tell them to go crazy.
1 like
Level 1
@martinbean this api is not for user ! suppose backend team using this api to run artisan command onto the server , if this api capable to run artissan command then it also run cat command so backend team can run cat /var/www/html/.env to get the .env file
I need to explain my concern: Suppose the backend team is trying to access the .env file through an API. Since we are all using a CI/CD pipeline, we are not always fully aware of the changes made by the backend team. Suppose they create an API that can interact through the CLI and access the .env file. I want a solution that will secure the .env file from being accessed through an API.
Level 80
this api is not for user !
@hritikoptiumbrew You keep saying this, but if an API is used, then it has users. Doesn’t matter if they‘re members of the public or internal staff members; they’re still users of the API, and they can still abuse it.
suppose backend team using this api
Backend team = users
suppose backend team using this api to run artisan command onto the server
Why are the backend team running commands via an API, and not on the server? If you don’t trust them to run the commands directly on the server, then you shouldn’t trust them to run commands via a HTTP API either.
Since we are all using a CI/CD pipeline, we are not always fully aware of the changes made by the backend team. Suppose they create an API that can interact through the CLI and access the .env file. I want a solution that will secure the .env file from being accessed through an API.
How about you just stop creating APIs that run arbitrary commands on servers, and do reviews on pull requests merging any code into your main branch? 🤷♂️ Code should not be getting merged and deployed without any one seeing it and reviewing it.
Besides, all of this is a non-issue any way, as you should be using environment variables proper in non-local environments, and not .env files.
1 like
Level 1
@martinbean, Thanks you , I understand your perspective. However, for better security purposes, I need to ensure that the .env file is secure in all scenarios. Is there a way to secure the .env file from being accessed through an API?
Level 104
@hritikoptiumbrew the .env file is not exposed publicly by default; only server misconfiguration or purposely allowing arbitrary code to be executed on the server will do that.
You also need to realise also that your .env file (or proper environment variables) are no longer relevant after the config has been cached. And, your malicious backend team can also access these sensitive credentials from the cached config if you are allowing them to write and deploy unchecked code.
1 like
Level 80
However, for better security purposes, I need to ensure that the .env file is secure in all scenarios. Is there a way to secure the .env file from being accessed through an API?
@hritikoptiumbrew Yes. By not allowing it to be accessed through an in the first place.
2 likes
Level 104
Suppose you hire a backend team you can trust?
3 likes
Level 75
The solution, main laravel does not go into a web folder.
1 like
Level 122
You dont trust your backend team and you have no way to stop them deploying arbritrary code? Never mind the env file, they can just add code that logs the output of the config command then look in the logs.
Just one of many ways to access your 'secrets'
1 like
Level 39
I believe the consensus here is clear:
What you are doing is highly discouraged under any circumstances. Although you haven't explicitly mentioned mistrust towards your backend team, I understand that the current setup was likely implemented to simplify operations for your team.
However, this approach is fundamentally unsafe, and it's important to consider alternative, more secure methods for executing commands like Laravel Artisan.
Here are my recommendations:
-
Avoid running sensitive commands through any public/private-facing API.
Even if your backend team is trusted, their credentials can be compromised, potentially granting an attacker unrestricted access to your environment. -
Restrict command execution to those with direct server access (SSH).
It’s much safer to allow a select group of users access to the server via SSH, where their actions can be logged and monitored. Backend developers shouldn't have unrestricted access—limit this privilege to a small, accountable group. Developers who need commands run should request this from that group. -
Developers should not have direct access to the production environment.
There should be a clear separation between development and production servers. Commands required in production should be part of the deployment process, reducing the risk of exposing sensitive information. Even if development environment credentials are compromised, the impact is far less critical than in production. -
Limit permissions for running commands.
No user should have the ability to run arbitrary commands freely. This level of access should be reserved for system administrators or a small group of trusted individuals. -
Regularly audit logs and enforce consequences.
Establish a clear protocol for reviewing logs and holding users accountable if they run commands outside of their permissions. Unauthorized actions should be met with appropriate sanctions to maintain a secure environment.
2 likes
Please or to participate in this conversation.