Snaver

This Beyond Code package provides a convenient mechanism for encrypting and then accessing 'secret credentials' https://github.com/beyondcode/laravel-credentials. Essentially you move the secrets out of the env file.

However this doesn't prevent the issue of leaking sensitive or secret information from stacktraces - being able to view the debug output in production is essentially the primary issue (as everyone else has pointed out).

klodj

I don't remember who said that (some comments are edited or removed) but I totally agee if you say this is a free framework and maybe you have to pay for having all the wholes closed. I totally agree with that!

36864
36864
3 months ago (61,750 XP)

this is a free framework and maybe you have to pay for having all the wholes closed.

Yes, you, the developer, are being paid to make sure there are no proverbial holes in your app. In this case, all you have to do is not put them there in the first place.

klodj

I mean paid framework. Like when you buy Microsoft Windows it has firewall enabled by default.

Yorki
Yorki
3 months ago (35,750 XP)

It does have nothing to do with framework being paid or not. Responsibility for not allowing to leak sensitive data is on developer side. If you can't configure two environment variables on production maybe it's better idea to change profession and become graphic designer or so.

click
click
3 months ago (74,930 XP)

I agree with all of the statements that you should not deploy anything to a live environment unless you know what you are doing.

But the reality is different. There are people who are deploying applications to live environments. And IMO it could not harm anybody if the default settings would protect the unexperienced developers here.

So I would vote for "security first" settings to prevent all of these accidental leaks of credentials. Is there any reason not to do it?

Do you remember the 'MongoDB no password gate' from last year? MongoDB by default did not set a password and was not restricted to localhost connections only. So if the developer did not configure this the database was open for everybody. You saw a lot of comments like: "stupid developers, why didn't they do this and that". Yep, totally agree. But... it happened.

After these hacks they changed their default configuration:

Helping direct users towards safe network options is why since release 2.6.0 we have made localhost binding the default configuration in our most popular deployment package formats, RPM and deb. This means all networked connections to the database are denied unless explicitly configured by an administrator.

So by default their settings are now 'secure' and if you want to open up your database you have to configure that manually.

Sources

36864
36864
3 months ago (61,750 XP)

Why must we appeal to the lowest common denominator? Do you also insist that lego bricks be made soft so people don't hurt themselves when they step on them? Do you blame the nails when someone does a poor job of building a shed and someone pricks their finger on an exposed nail? Maybe hammers should come with built-in thumb detectors and airbags to prevent people from hitting their own fingers.

Laravel is as secure as you want it to be. If you're deploying an app to a production environment, you need to know how to set up your environment and protect your data. This is not optional.

The dotenv library isn't even meant for production environments, it's a development tool. If you rely on development tools to configure your production environment, you need to make yourself aware of what the associated risks are.

If you look at a variable named APP_DEBUG and set it to true when deploying to production, you should really consider a career change.

click
click
3 months ago (74,930 XP)

@36864 but what would be a reason to not set the default configurations to protect the developer?

The argumentation: "you should really consider a career change if you can't do this and that" is not a valid argument IMO. Not everybody is using Laravel on a professional level. Accept the fact that is happening. Why wouldn't we protect them with a simple default configuration? I think the pro's are bigger than the cons in this case.

36864
36864
3 months ago (61,750 XP)

Pros:

  • Neglectful devs won't leak their passwords online

Cons:

  • Additional steps to get full debug information during development
  • Neglectful devs will continue to be sloppy and fail to properly set up their environments, possibly leading to severe problems down the road.

Feel free to complete the list.

jlrdw
jlrdw
3 months ago (245,870 XP)

I think one of the main problems is:

Laravel is so popular that people new to programming start with it.

Meaning they have no

  • HTML
  • PHP
  • CSS
  • Security Training

first. There are folks on the forum who's been learning laravel for a while who have no idea about the OWASP site. No idea what CSRF or XSS is.

Even the skilled trades such as an electrician has to go through an apprenticeship program, usually 4 years.

A good developer on their own studies topics to learn correctly, but many newbees plunge into laravel and think or act as if laravel was like a magic code generator that auto handles everything.

It's not, it's a php framework.

So I agree the developer should implement proper security, etc.

But a real developer is the ones who have learned correctly, not the ones who started with laravel and 3 weeks later call themselves developers.

klodj

@martinbean good for you and I admire your achievements, but I didn't start this conversation to to show mines, cause I also have been programming since qbasic and pascal. Here I took the courage to raise this issue as behalf of one of my students, who by the way thank you for your suggestion @Yorki one career in programming is over after risking to go to jail at his first project... a password is like loosing the keys of the house!

@Cronix you are lucky man, I bet you work in a team where nothing is left unchecked and have a 'replica' in case you fail, but I doubt you have been in a project where everything is expected only from you, everything... servers, networking, db, programming, maintenance and so on!!!

@Snapey I didn't find that in the documentation but in stackoverflow, and what I'm asking or suggesting is nothing else than making it default (like windows firewall).

@jlrdw and @click thanks for your endorsements, if somebody else want this fixed just don't be afraid to give a thumbs up. There is nothing to be embarrassed - I'm with Messi even after loosing the penalty! Look at his team they are all losers and they have the courage to blame him.

@36864 oh you had a typo in your password - copy/pasted I guess - anyway you really made me laugh thank you

Cronix
Cronix
3 months ago (733,460 XP)

you are lucky man, I bet you work in a team where nothing is left unchecked and have a 'replica' in case you fail, but I doubt you have been in a project where everything is expected only from you, everything... servers, networking, db, programming, maintenance and so on!!!

I did that for 12 years as an independent contractor when I started my company. I've built some very large, high traffic, multi-million dollar sites that are still running and generating a lot of revenue ;) And most of these automated tools and frameworks we have today to do this stuff for you didn't exist. So you really actually had to know things. But thanks for assuming. ;)

klodj

@Cronix the problem is as simple as the solution, can you endorse me on this? After this feature was added to Laravel the guy who created it stated very well that this needs to be default. You can check it if you want in github.

Snapey
Snapey
3 months ago (998,475 XP)

bored

Cronix
Cronix
3 months ago (733,460 XP)

Should laravel build the server for people too, to protect them from their own lack of knowledge? I see way to many people improperly set up their servers, especially shared hosting, and you can access .env directly and see all of the raw credentials.

Like this guy who I told about it 2 days ago and still hasn't fixed it: http://admin.creativehedgehog.co.uk/.env

Please sign in or create an account to participate in this conversation.