Laravel security issue

Because .env file is publicly accessible? This would not be a Laravel security issue, it is an issue with how you have deployed your website.

How I can access it because I try already - it is not in the public dir?

Maybe this is something related https://vuldb.com/?id.109743 but I can find a fix

I already told all files has proper permission - what else you mean by proper installation

How do you know someone read your .env file?

Are you exposing the local Whoops page on any error/exception?

@devonblzx because he sent me a screenshot and ask me for money.

@tykus app debug is false also APP_ENV=production - so No

Share the screenshot. It'd be hard for us to tell you how he gained access to your .env without getting a lot more info about your site and this exchange.

You may want to just hire a security consultant if you're concerned, but I'm fairly confident there is no .env vulnerability in Laravel itself. It's very possible a package you're using or an invalid hosting setup could lead to exposure though.

Didn't he just get in your server instead? Or do you have some logic in your application where you can download files where the path is passed to the application like? download/?path=../.env ? Shared hosting? Server credentials are set and not set to a default easy to guess password?

Check the last logins on your server with last | head -20 see if you see anything odd.

Btw, I should remove the link from this topic. If that sites wants to sell anything it would be a bad idea to post full url's here because google will pass by this ticket soon and will find your url.

@devonblzx He just sent me a screenshot of passwords in the env what you can see from there.

And here are the only packages I add to this installation

"skovmand/mailchimp-laravel": "1.*", "spatie/calendar-links": "^1.0", "vibar/laravel-account": "^0.2.0"

I think there is nothing related to how he got the info in the .env file

@m-rk I dont have a download it is just login register and few sample forms with input text only. Not shared it is AWS.

And this is the only site you have on that server? And you haven't temporarily turned on debug or changed the environment at any point in time?

Does your site have any sort of file upload in combination with a 777 directory or missing validation?

You should figure out if he/she got it directly from your server. Check for strange logins directly on your aws server.

Do you have any third party services that are connecting to your aws? Like deployment scripts? Backup tools? Monitors?

Is it possible he got the .env file from somewhere else and not your production environment? Like your local machine, a github/bitbucket/gitlab commit to an open source codebase? Email send to wrong colleague.

note: I suppose you already did but change your passwords from your database and any other passwords api keys that were in your .env file. Probably you also want to refresh you application key it self.

Is the screenshot of your actual .env file or of an error screen that contains your environment variables?

@martyy The reason I asked was if the screenshot had any details about where the env came from, if he had the full .env file, or just a couple passwords that match.

Of course, don't share the sensitive parts of your .env, but I was assuming there may be something useful in the way the screenshot was structured (entire .env, partial .env, a URL, way it was presented). May give some insight into how it was accessed.

Especially since your web site seems to be geared around future financial transactions, a forum is not the right place for this to be diagnosed. You need to get a trusted consultant who can actually diagnose if the server or code has a vulnerability if this data was obtained.

@36864 my actual file - if it was debugging screen I`ll not create a topic here.

Also, as I say - the debug is false and app_env=production

@devonblzx It is partial .env I think - also the website doesn't have any financial transactions for now.

I think this is known bug in Laravel because the guy is not a programmer or even technical and he makes this because somewhere in the deep web is shared something for this bug.

Are you on a shared hosting? Could your environment variables have been exposed to another site on the same host? There is a thread here which appears to suggest (I have only speed-read the thread) it is possible for environment variables to leak across different sites especially when there might be a long running request. There is a Laravel/Dotenv discussion which suggests that it is paramount to cache your config to avoid this behaviour.

Does any of this seem reasonable?

@martyyy It ain't a 'known bug' in Laravel. If you are serious with your business you should investigate what is going on with your application.

How do you know the guy is not a programmer or technical? Is he sitting in the office next to you? Maybe he read the post-it on your screen with the root password to your AWS system....

If you have your environment file under Webroot anyone in the world can read it Again install the framework and place the folders correctly. Proper installation has been covered countless times right here.

However if and only if you have the framework properly set up and if that file can still be read then the proper course of action is to contact Taylor otwell himself and inform him of a security issue. He States this in the documentation.

Another option is to hard-code the configuration data in the individual configuration files Which is what I do for a production environment.

The topic starter already mentioned:

• server is hosted on aws (so not shared)
• .env is outside public directory

I don't think creating a ticket for taylor won't help you if you do not know how this has happened. He will start asking the same question that were asked here. So that should be answered first. For example, check the last logins on your server. Is there any other way your .env could get leaked? Are there third party services that have access to your server (backups, deployment tools, etc.)

Btw, isn't it possible that your .env was exposed just by adding /.env to your domain but that was before you updated your server configuration?

Then check laravel issues on github and see if it has been addressed. Maybe all that is needed is to update laravel to a version higher than the affected version.

If there is not an issue already, create one and post all this info for Taylor to study, or give link to this forum post.

No @m-rk I already checked this with the domain and .env also with file_get_contents it is not accessible

What is your exact laravel version? 5.5.* is pretty vague. Your PHP version would also be helpful.

Version is Laravel 5.5.40

you shouldn't upload your local or production env files

Of course, I don't do this @j_ro why it is outside of my repository

take a look at this https://github.com/v4p0r/ENV-Mass-Exploit

@muhi Looking at that script, it does nothing special that anybody can't do by typing a web address followed by .env. The only way that script can get the .env file is if the developer set up their host incorrectly, most likely on shared hosting. If you can go to yoursite.com/.env and view the env file, your site is set up improperly. That's all that script does, is check the list of sites you feed it to see if you can publicly view the .env file. You can actually get more results by searching .env on google.

For instance searching for "filetype:env" in google yielded these results, among thousands of others. This doesn't mean .env is insecure, or there's some leet skript kiddies running around with some voodoo magic way to hack your .env. It means the people who put these sites up don't know *hit about setting their host up securely and didn't make the /public dir the web root. They made the base dir of laravel the root.

http://www.evergraceltd.com/appserver/.env

http://vbought.com/rapidxpres/.env

http://sharefb.com/server/.env

I`m not sure at all what the default auth of Laravel dont strip_tags on name field and I can see in my DB things like this '>< script src=https://test1xssht.xss.ht > < / script >' :)

oh dear.

You have to cleanse the data yourself before saving to the database, eg html purifier

If you are taking user input, putting it in the database as supplied, you are still protected in the main by escaping output with {{ }}

But, if your db credentials are exposed, the original attacker could have put those values there in the database directly