[Laravel] Security

[PieterjanDC]

Hallo,

Ik heb een website die geprogrammeerd is met het Laravel framework.
Ik draai deze website op 1 server. Ik weet dat het aanbevolen is om 2 omgevingen te hebben, 1 om te testen en 1 die public is. Maar ik heb hier de tijd en het geld niet voor om 2 servers te onderhouden.

Onlangs kreeg ik een e-mail van een gebruiker waarin hij vertelde dat mijn wachtwoord van mijn SQL-server gewoon op een foutpagina geblurd werd (security ). Dit was natuurlijk op een split second terwijl ik aan het testen was op mijn server... Anders staat mijn website gewoon in public mode.

Eerst geloofde ik niet dat een populair framework het aandurft om gewoon de environment variabelen print op een HTML-pagina. Ik heb dit gecontroleerd en dit is gewoon volledig waar... Ik heb het niet over een gebruiker zijn wachtwoord, neen HET SQL WACHTWOORD van mijn server...

Ik heb dit gemeld aan de ontwikkelaars van Laravel, maar zij zien niet het minste probleem in gewoon een SQL-wachtwoord printen op een webpagina. Ze zijn absoluut niet van plan om dit te veranderen.

Nu mijn vraag... Als een MVC framework zo idioot is om de secrets van een een applicatie gewoon te printen in HTML, welke andere idiote security issues kunnen er dan nog naar boven komen? Is het nog verstandig om deze website te blijven hosten of dit framework te blijven gebruiken?

Ik ben van plan om gewoon alle users uit mijn database te verwijderen en mijn authenticatie systeem te disablen. Dan is de website natuurlijk dood (alhoewel hij live zal blijven...)

Moet ik ook deze gegevens doorgeven aan HaveIBeenPwned?

[DynaSpan]

Het probleem zit hier IMO niet in het framework maar bij jou. Er is een reden waarom je een 'debug/test' modus en 'productie' modus in frameworks hebt. Dat alle environment vars worden geprint wanneer de applicatie in debug modus draait is niet vreemd.

[Montaner]

Een extra server onderhouden? Wacht dacht je van virtualisatie? Je moet je eigen probleem niet verleggen naar een ander.

[418O2]

Je kan toch testen op je lokale machine als je geen testomgeving kan betalen?

"Gevoelige" informatie in foutmeldingen in een dev env is niet zo raar

[Verwijderd]

-

[ Voor 99% gewijzigd door Verwijderd op 19-10-2019 16:11 . Reden: Leeg ivm privacy ]

[BladeSlayer1000]

Je hoeft niet persé een tweede server hiervoor aan te schaffen. Voor mijn site ontwikkel ik eerst alles lokaal op de PC. Dit kan met behulp van XAMPP om het als ik alles zo ver heb getest vervolgens op de server live te zetten.

Denk hierbij wel dat je instellingen moet veranderen in Laravel.

[ Voor 8% gewijzigd door BladeSlayer1000 op 06-12-2018 10:14 ]

[reb3lzrr]

Ik weet natuurlijk niet wat voor website dit is, en of dit een hobbyproject is of echte klanten van je zijn. Maar in ieder geval ben je onprofessioneel bezig:
- Je kan niet zo maar gaan 'iets gaan testen' op hun productie omgeving
- Je omgeving is misgeconfigureerd (zoals aangegeven door @Verwijderd ) wat tot een serieuze security breach geleid heeft.

Oké nu een stukje pragmatischer:

Databreach
Zoals je zei heb je dus nu de conclusie getrokken dat mensen toegang gehad kunnen hebben tot je SQL database, -ik behandel zo even de wachtwoorden- als je persoonsgegevens opslaat ben je verplicht dit te melden aan de Autoriteit Persoonsgegevens en de gebruikers. Ik hoop dat je ondertussen het SQL wachtwoord gewijzigd heb...

Wachtwoorden
Een modern framework gebruikt hashing + salt om indirecte informatie over het wachtwoord op te slaan. Indien dat zo is zullen de wachtwoorden niet uitgelekt zijn, alleen deze indirecte informatie. Check dus of dat bij jouw framework ook het geval is. Meld dit ook aan je gebruikers.

**edit: linkje toegevoegd

[ Voor 10% gewijzigd door reb3lzrr op 06-12-2018 10:25 ]

[PieterjanDC]

SQL-wachtwoord natuurlijk direct gewijzigd

Wachtwoorden zijn ge-bcrypt dus dat is alvast geen probleem.

Email adressen staan gewoon in plaintext en dus ja... Ik wil echt verantwoordelijkheid nemen en zal dit dus zeker melden aan het punt dat je vermeld hebt.

Kan ik weten of er ingelogd is via PhpMyAdmin of op mijn MySql-server?

[ Voor 21% gewijzigd door PieterjanDC op 06-12-2018 10:41 ]

[Stoelpoot]

Dit was natuurlijk op een split second terwijl ik aan het testen was op mijn server... Anders staat mijn website gewoon in public mode.

Het probleem zit dus, zoals hierboven al aangegeven, niet in Laravel. Als jij Laravel uit public mode haalt, dan zal Laravel dus debug-informatie weergeven.

Wat betreft je tweede vraag, dit ligt er aan hoe logging is ingesteld op je server. Mogelijk heeft PHPMyAdmin logs gemaakt, mogelijk heeft MySQL logs bijgehouden van directe logins.

[reb3lzrr]

PieterjanDC schreef op donderdag 6 december 2018 @ 10:37:
Wachtwoorden zijn ge-bcrypt dus dat is alvast geen probleem.

Alleen bcrypt vertelt me niks over de salt; een goede indicatie is om te kijken of er ook een salt staat opgeslagen in de 'user/gebruiker' tabel.

PieterjanDC schreef op donderdag 6 december 2018 @ 10:37:
Email adressen staan gewoon in plaintext en dus ja... Ik wil echt verantwoordelijkheid nemen en zal dit dus zeker melden aan het punt dat je vermeld hebt.

Melden is alleen nodig als het over persoonsgegevens gaat, dat wordt ongeveer als volgt gedefineerd:

"Een persoonsgegeven is een gegeven dat herleidbaar is naar een natuurlijke persoon die geïdentificeerd is, of kan worden geïdentificeerd. Deze gegevens kunnen bestaan uit tekst, beeld en geluid"

**edit: persoonsgegevens definitie toegevoegd

[ Voor 49% gewijzigd door reb3lzrr op 06-12-2018 10:52 ]

[Stoelpoot]

reb3lzrr schreef op donderdag 6 december 2018 @ 10:46:
[...]

Alleen bcrypt vertelt me niks over de salt; een goede indicatie is om te kijken of er ook een salt staat opgeslagen in de 'user/gebruiker' tabel.

Niet In PHP. PHP kent van zichzelf hashing-functies, die de salt, de hash en het hash-algo opslaan als composiete string-waarde. Als BCrypt wordt gebruikt, is er een goede kans dat de PHP hashing-functies zijn gebruikt.

[ThomasG]

Stoelpoot schreef op donderdag 6 december 2018 @ 10:51:
[...]


Niet In PHP. PHP kent van zichzelf hashing-functies, die de salt, de hash en het hash-algo opslaan als composiete string-waarde. Als BCrypt wordt gebruikt, is er een goede kans dat de PHP hashing-functies zijn gebruikt.

Dat heeft helemaal niets met PHP te maken. Dat is gewoon hoe BCrypt werkt. Een BCrypt hash bestaat uit 4 delen: prefix sterkte, salt en hash.

Ter illustratie, bij het shadow password (resultaat van BCrypt) $2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy is $2a$ de prefix, 10 de strength, N9qo8uLOickgx2ZMRZoMye de salt en IjZAgcfl7p92ldGxad68LJZdL17lhWy de hash.

[ Voor 22% gewijzigd door ThomasG op 06-12-2018 11:23 ]

[NMe]

418O2 schreef op donderdag 6 december 2018 @ 10:07:
Je kan toch testen op je lokale machine als je geen testomgeving kan betalen?

"Gevoelige" informatie in foutmeldingen in een dev env is niet zo raar

Gevoelige informatie is tot daaraan toe maar wachtwoorden erin gaan zetten is ronduit debiel. Die zijn echt niet relevant als debuginformatie en hebben niks op zo'n pagina te zoeken. Het is zeker niet handig van OP om zijn productieserver in debug-modus te zetten maar tegelijkertijd is het Laravel IMO zéker aan te rekenen als het dit soort waardes gewoon afdrukt.

[Kalentum]

Over het melden van data lekken: Dat hoeft toch alleen als er een persoonsgegeven gelekt is? Dus dan moeten die persoonsgegevens wel gelekt zijn.

Het feit dat een database wachtwoord bekend is wil nog niet zeggen dat iemand toegang heeft tot die database. Normaal gesproken hangt een database server achter een firewall of op een server die niet rechtstreeks te benaderen is.

[NMe]

rutgerw schreef op donderdag 6 december 2018 @ 12:30:
Over het melden van data lekken: Dat hoeft toch alleen als er een persoonsgegeven gelekt is? Dus dan moeten die persoonsgegevens wel gelekt zijn.

Het feit dat een database wachtwoord bekend is wil nog niet zeggen dat iemand toegang heeft tot die database. Normaal gesproken hangt een database server achter een firewall of op een server die niet rechtstreeks te benaderen is.

Klopt, maar die is dan wel weer lullig: als het wachtwoord gelekt is op dag 1 en de databaseserver per ongeluk vanaf buiten bereikbaar is op dag 2 en je in de tussentijd het wachtwoord niet hebt aangepast dan heb je in feite een datalek. Het zou wel heel toevallig zijn als dat allemaal net zo uitkomt dat iemand er ook echt gebruik van maakt maar hier zou je wel een meldplicht voor hebben volgens mij.

[Koozza]

@PieterjanDC Let er even op dat als je App in test mode staat dat de gehele .env file getoond wordt op een whoops melding. Daarin staat ook je App key die gebruikt wordt voor het hashen. Die zou ik dus ook zeker aanpassen. Let wel op dat dan je wachtwoorden niet meer werken.

NMe schreef op donderdag 6 december 2018 @ 11:49:
[...]

Gevoelige informatie is tot daaraan toe maar wachtwoorden erin gaan zetten is ronduit debiel. Die zijn echt niet relevant als debuginformatie en hebben niks op zo'n pagina te zoeken. Het is zeker niet handig van OP om zijn productieserver in debug-modus te zetten maar tegelijkertijd is het Laravel IMO zéker aan te rekenen als het dit soort waardes gewoon afdrukt.

Als ik het goed heb is het niet laravel die deze gegevens print. Dit is een package: https://github.com/filp/whoops die standaard met elke laravel installatie komt. Deze print bij een error de volledige envoirement file (welke IMO wel handig kan zijn voor debug doeleinden).

[Qoncritter]

NMe schreef op donderdag 6 december 2018 @ 11:49:
[...]

Gevoelige informatie is tot daaraan toe maar wachtwoorden erin gaan zetten is ronduit debiel. Die zijn echt niet relevant als debuginformatie en hebben niks op zo'n pagina te zoeken. Het is zeker niet handig van OP om zijn productieserver in debug-modus te zetten maar tegelijkertijd is het Laravel IMO zéker aan te rekenen als het dit soort waardes gewoon afdrukt.

Ik snap je punt maar wat er ook nog bij komt is dat Whoops standaard in de dev-dependencies staan. Dus is er al een verkeerde composer install gedraaid. Je moet namelijk "composer install --no-dev" draaien op je productie server of build tool.

[ Voor 0% gewijzigd door Qoncritter op 06-12-2018 13:34 . Reden: Typo ]

[NMe]

Koozza schreef op donderdag 6 december 2018 @ 13:28:
Als ik het goed heb is het niet laravel die deze gegevens print. Dit is een package: https://github.com/filp/whoops die standaard met elke laravel installatie komt.

Als het standaard in Laravel zit heeft het Laravel-team er bewust voor gekozen en is het dus "verantwoordelijk" voor het feit dat er gevoelige info in dit scherm terecht komt.

Qoncritter schreef op donderdag 6 december 2018 @ 13:34:
[...]

Ik snap je punt maar wat er ook nog bij komt is dat Whoops standaard in de dev-dependencies staan. Dus is er al een verkeerde composer install gedraaid. Je moet namelijk "composer install --no-dev" draaien op je productie server of build tool.

Klopt als een bus maar óók op de dev-omgeving is het ronduit achterlijk om wachtwoorden af te lopen drukken in je errormeldingen.

[Verwijderd]

-

[ Voor 120% gewijzigd door Verwijderd op 19-10-2019 16:11 . Reden: Leeg ivm privacy ]

[pottink]

Staat de debug flag wel op false in je .env file? Deze moet in productie gewoon op false staan en dan krijg je toch die gedetailleerde foutmeldingen niet?

[418O2]

pottink schreef op donderdag 6 december 2018 @ 22:28:
Staat de debug flag wel op false in je .env file? Deze moet in productie gewoon op false staan en dan krijg je toch die gedetailleerde foutmeldingen niet?

Die zet hij bij testen dan op true blijkbaar.

Misschien niet de beste keus, maar je wil hoe dan ook niet de debugmode op productie aan hebben staan

[Barryvdh]

NMe schreef op donderdag 6 december 2018 @ 14:43:
[...]

Als het standaard in Laravel zit heeft het Laravel-team er bewust voor gekozen en is het dus "verantwoordelijk" voor het feit dat er gevoelige info in dit scherm terecht komt.

[...]

Klopt als een bus maar óók op de dev-omgeving is het ronduit achterlijk om wachtwoorden af te lopen drukken in je errormeldingen.

De enige die hier "verantwoordelijk" voor is, is degene die blind 'dev' dependencies installeert op een productieomgeving + APP_DEBUG aan zet.
Het staat overigens ook in de documentatie:
https://laravel.com/docs/...ment-variables-from-debug

When an exception is uncaught and the APP_DEBUG environment variable is true, the debug page will show all environment variables and their contents. In some cases you may want to obscure certain variables. You may do this by updating the debug_blacklist option in your config/app.php configuration file.

Al is er natuurlijk iets voor te zeggen om dat default toe te voegen. Ik zou zeggen, maak een PR.

Koozza schreef op donderdag 6 december 2018 @ 13:28:
@PieterjanDC Let er even op dat als je App in test mode staat dat de gehele .env file getoond wordt op een whoops melding. Daarin staat ook je App key die gebruikt wordt voor het hashen. Die zou ik dus ook zeker aanpassen. Let wel op dat dan je wachtwoorden niet meer werken.

Dit is overigens niet waar. de APP_KEY wordt gebruikt voor encryptie, niet voor hashing. Heeft dus niks te maken met je wachtwoorden, die zijn gewoon veilig gehashed met bcrypt+unieke salt. Wel moet je die veranderen, aangezien die wel gebruikt wordt voor bijv. het valideren van je cookies ed. (Dus is te manipuleren als je de key weet)

Ps. je bent overigens niet de enige hoor nieuws: Actiesite Kleenex had datalek door debugbalk onder in beeld

Ps. 2, als je op begint te schreeuwen in je Issue, zou ik je ook niet meer helpen: https://github.com/laravel/framework/issues/26750

[Olaf van der Spek]

Barryvdh schreef op vrijdag 7 december 2018 @ 10:07:
De enige die hier "verantwoordelijk" voor is, is degene die blind 'dev' dependencies installeert op een productieomgeving + APP_DEBUG aan zet.

Daar is duidelijk niet iedereen het over eens. Het is ook de verkeerde houding en de verkeerde vraag.

PieterjanDC schreef op donderdag 6 december 2018 @ 10:37:
Kan ik weten of er ingelogd is via PhpMyAdmin

Webserver access logs?

of op mijn MySql-server?

Volgens mij niet. Zit die server niet alleen op localhost?

[ Voor 36% gewijzigd door Olaf van der Spek op 07-12-2018 11:39 ]

[mcDavid]

NMe schreef op donderdag 6 december 2018 @ 11:49:
[...]

Gevoelige informatie is tot daaraan toe maar wachtwoorden erin gaan zetten is ronduit debiel. Die zijn echt niet relevant als debuginformatie en hebben niks op zo'n pagina te zoeken. Het is zeker niet handig van OP om zijn productieserver in debug-modus te zetten maar tegelijkertijd is het Laravel IMO zéker aan te rekenen als het dit soort waardes gewoon afdrukt.

Nou nou, dat gaat wel erg ver. Ja natuurlijk heeft een wachtwoord in een stack-trace (meestal) geen toegevoegde waarde en zou je ze er liever niet in zien. Maar heb jij een goeie manier om alle passwords uit alle stack traces te filteren dan? Voor sommige specifieke situaties zou je ze misschien kunnen filteren. Maar precies bijhouden op welke plekken passwords in stack traces terecht zouden kunnen komen is a hell of a job. Om niet te zeggen niet te doen.

Het grote probleem is hier toch echt dat errors uitlekken naar de client. Dat had op de eerste plaats al niet mogen gebeuren. Niet alleen vanwege de mogelijkheid dat er een password in staat, er zijn nog legio andere redenen waarom je dat niet moet willen.

[Olaf van der Spek]

mcDavid schreef op vrijdag 7 december 2018 @ 11:40:
Nou nou, dat gaat wel erg ver. Ja natuurlijk heeft een wachtwoord in een stack-trace (meestal) geen toegevoegde waarde en zou je ze er liever niet in zien. Maar heb jij een goeie manier om alle passwords uit alle stack traces te filteren dan? Voor sommige specifieke situaties zou je ze misschien kunnen filteren. Maar precies bijhouden op welke plekken passwords in stack traces terecht zouden kunnen komen is a hell of a job. Om niet te zeggen niet te doen.

Dit gaat niet over stacktraces..
Maar waarom zouden wachtwoorden in stacktraces / functie argumenten gebruikelijk zijn?

[ Voor 6% gewijzigd door Olaf van der Spek op 07-12-2018 11:43 ]

[mcDavid]

Olaf van der Spek schreef op vrijdag 7 december 2018 @ 11:41:
[...]

Dit gaat niet over stacktraces..
Maar waarom zouden wachtwoorden in stacktraces / functie argumenten gebruikelijk zijn?

Hoe wou jij een database-connectie opzetten zonder daar een password aan mee te geven? Of een user authenticeren... of whatever?

[Olaf van der Spek]

mcDavid schreef op vrijdag 7 december 2018 @ 11:47:
[...]


Hoe wou jij een database-connectie opzetten zonder daar een password aan mee te geven?

https://mariadb.com/kb/en...ation-plugin-unix-socket/

Of een db lib die het wachtwoord (en andere configuratie) zelf uit een bestand leest.

Of een user authenticeren... of whatever?

PHP:

password_verify(input('password'), $hash)

Tenzij password_verify() een exceptie gooit heb je nergens dat plaintext wachtwoord in een stacktrace toch?
En zelfs als je dat wel hebt is dat het wachtwoord wat de gebruiker zelf net heeft ingevoerd.

[dvdheiden]

Laten we allereerst even twee punten bespreken:

1. De dev dependencies uit composer.json horen niet online te staan. Een deployment tool als Envoyer regelt dit al voor je. Als je het handmatig doet:
   code:
   

   composer install --no-dev

   Wanneer je nog FTP gebruikt, dan moet je dus eerst lokaal dat commando draaien en daarna pas uploaden. Al raad ik je altijd aan een deployment tool te gebruiken.
2. Debuggen/testen doe je niet op de live omgeving maar op je lokale omgeving (in je productie omgeving hoor je nooit en te nimmer de APP_DEBUG op true te zetten). Daar hoef je overigens geen extra server voor te hebben of extra kosten te maken. Met allemaal gratis tools kan je je Laravel website lokaal testen. Afhankelijk van je platform zijn er diverse tools beschikbaar. Als je hier hulp bij nodig hebt, laat het gerust in dit topic weten dan kunnen wij je de goede kant op sturen.

Nu we dat hebben besproken, blijft je opmerking over dat een development package (wat de Whoops package is) geen wachtwoorden mag tonen. Ik zie niet helemaal het probleem, want zo weet je zeker dat je juiste credentials worden gebruikt. Andere kant kan ik mij wel voorstellen dat het wellicht wat raar aanvoelt maar wetende dat het een development package is kan ik mij niet zo vinden in jouw verontwaardiging. Het is daarnaast een gedocumenteerd effect, dus als je de docs leest komt dit ook naar voren.

Als laatste over je issue op GitHub, met een goede open discussie bereik je een stuk meer dan door boos te worden.

[ Voor 3% gewijzigd door dvdheiden op 07-12-2018 12:09 . Reden: Nederlands is moeilijk ]

[mcDavid]

Olaf van der Spek schreef op vrijdag 7 december 2018 @ 11:53:
[...]

https://mariadb.com/kb/en...ation-plugin-unix-socket/

Of een db lib die het wachtwoord (en andere configuratie) zelf uit een bestand leest.

Op lang niet alle hosting omgevingen heb je dat soort modules tot je beschikking. En een DB-lib kan ook een exception gooien.

[...]

PHP:

password_verify(input('password'), $hash)

Tenzij password_verify() een exceptie gooit heb je nergens dat plaintext wachtwoord in een stacktrace toch?
En zelfs als je dat wel hebt is dat het wachtwoord wat de gebruiker zelf net heeft ingevoerd.

Hoe komt dat password bij password_verify() terecht dan? Meestal via $_POST en laat dat nou net interessante informatie zijn die je in een foutmelding (meestal) graag wilt zien... En behalve bij degene die het wachtwoord ingevoerd heeft, heb je ook zomaar kans dat het in een error log terecht komt.

Helaas is de praktijk nogal weerbarstig

[Olaf van der Spek]

mcDavid schreef op vrijdag 7 december 2018 @ 12:04:
[...]
Op lang niet alle hosting omgevingen heb je dat soort modules tot je beschikking. En een DB-lib kan ook een exception gooien.

Kan, maar dan kan ie er ook rekening mee houden dat de stacktrace geen wachtwoord bevat.

Hoe komt dat password bij password_verify() terecht dan? Meestal via $_POST en laat dat nou net interessante informatie zijn die je in een foutmelding (meestal) graag wilt zien... En behalve bij degene die het wachtwoord ingevoerd heeft, heb je ook zomaar kans dat het in een error log terecht komt.

De error log is niet world readable.. hopelijk.

[mcDavid]

Olaf van der Spek schreef op vrijdag 7 december 2018 @ 12:07:
[...]

Kan, maar dan kan ie er ook rekening mee houden dat de stacktrace geen wachtwoord bevat.

Het vervelende van exceptions is nou juist dat ze vaak tevoorschijn komen op het moment dat er iets gebeurt waar je van tevoren *niet* aan gedacht had

[...]

De error log is niet world readable.. hopelijk.

Wat is precies het punt dat je hiermee wilt maken? Net was dat nog dat passwords niet in backtraces horen, nu dat het niet uit maakt dat ze er in staan?

begrijp me niet verkeerd, ik ben het er helemaal mee eens dat je in een ideale wereld liever nooit ergens een plain-text wachtwoord zou zien opduiken. Ik wil alleen aangeven dat dit in de praktijk vrijwel onhaalbaar is.

[ Voor 15% gewijzigd door mcDavid op 07-12-2018 12:14 ]

[Olaf van der Spek]

mcDavid schreef op vrijdag 7 december 2018 @ 12:12:
[...]
Het vervelende van exceptions is nou juist dat ze vaak tevoorschijn komen op het moment dat er iets gebeurt waar je van tevoren *niet* aan gedacht had

Als dev van DB libs is het handig daar wel aan te denken.
Als we wat stappen terug nemen en het grote geheel bekijken is een optie bijvoorbeeld om ervoor te zorgen dat DB wachtwoorden niet door PHP code worden behandeld maar door de C code van PHP zelf.

[...]

Wat is precies het punt dat je hiermee wilt maken? Net was dat nog dat passwords niet in backtraces horen, nu dat het niet uit maakt dat ze er in staan?

We hadden het nu over de error log, toch? Is niet hetzelfde als een back/stacktrace.
En het wachtwoord dat een gebruiker net invoert is niet hetzelfde als het DB wachtwoord.
En $_POST zou ik ook niet zomaar naar de error log schrijven.

[ Voor 8% gewijzigd door Olaf van der Spek op 07-12-2018 12:18 ]

[NMe]

Barryvdh schreef op vrijdag 7 december 2018 @ 10:07:
[...]

De enige die hier "verantwoordelijk" voor is, is degene die blind 'dev' dependencies installeert op een productieomgeving + APP_DEBUG aan zet.

Je begrijpt mijn punt niet. Ook op de dev-omgeving is dit nutteloze en mogelijk zelfs onwenselijke data om af te drukken.

mcDavid schreef op vrijdag 7 december 2018 @ 11:40:
[...]

Nou nou, dat gaat wel erg ver. Ja natuurlijk heeft een wachtwoord in een stack-trace (meestal) geen toegevoegde waarde en zou je ze er liever niet in zien. Maar heb jij een goeie manier om alle passwords uit alle stack traces te filteren dan? Voor sommige specifieke situaties zou je ze misschien kunnen filteren. Maar precies bijhouden op welke plekken passwords in stack traces terecht zouden kunnen komen is a hell of a job. Om niet te zeggen niet te doen.

Stacktraces bevatten variabelen, geen constantes. Je zou daar gewoon iets moeten zien als DB_PASSWORD en niet 'm1jn5uperg4vew8w00rdh13r'.

[Groax]

Ik heb niet alles gelezen maar als je in je .env file de regel (APP_DEBUG) op FALSE zet moet dit de wachtwoorden van je beschermen. sla ook al je wachtwoorden op in je .env file. hier zijn ze 'veilig'

zorg ook dat je wachtwoorden niet in controllers, models of views zet want je gaat ze zien... misschien ook error handling uit zetten op je server?

[Barryvdh]

NMe schreef op vrijdag 7 december 2018 @ 13:58:
[...]

Je begrijpt mijn punt niet. Ook op de dev-omgeving is dit nutteloze en mogelijk zelfs onwenselijke data om af te drukken.

Klopt, daarom wijzen ze daarop in de documentatie en leggen ze uit hoe je bepaalde data kan verbergen. Ik bedoel alleen maar dat het niet de schuld is van de ontwikkelaar als jij de software op een manier gebruikt die zij niet bedoelden.

[Siebsel]

NMe schreef op vrijdag 7 december 2018 @ 13:58:
[...]

Je begrijpt mijn punt niet. Ook op de dev-omgeving is dit nutteloze en mogelijk zelfs onwenselijke data om af te drukken.

Absoluut niet mee eens... Ik verander regelmatig stuff in mijn env om dingen te testen. Bijvoorbeeld de queue driver, bepaalde cachetimeouts, etc. Als ik dan een error op m'n neus krijg, is het handig dat ik snel kan zien of bijvoorbeeld mijn queue driver op 'sync' of 'redis' staat, of dat ik wel/geen cache timeout geconfigged heb, etc.

Wachtwoorden ben ik met je eens, dat is niet nodig, maar zo'n env weet het verschil natuurlijk niet tussen een setting en een wachtwoord. En imho hebben ze daar gewoon een solid oplossing voor bedacht. (waarbij ik het ook eens ben met barryvdh, een aantal defaults hadden ze daar wel voor kunnen configureren)

edit: of had je het specifiek over wachtwoorden? Dan zijn we het geloof ik wel eens

[ Voor 4% gewijzigd door Siebsel op 07-12-2018 15:09 ]

[Lethalis]

Zelfs al zou je niet lokaal willen testen en geen virtuele machines of dockers willen maken, dan nog kun je de meest basale oplossing kiezen: plaats de testsite op een andere url.

Productie: www.webapp.nl
Test: test.webapp.nl

Voor de rest ben ik ook geen enorme fan van wachtwoorden in de environment variabelen. Ja, ze zijn op Linux wel beveiligd en alleen voor de user toegankelijk, en het is lekker makkelijk met Docker containers om configuratie mee te geven, maar ik blijf het tricky vinden.

In de .NET wereld is dit opgelost met een XML transformatie van het Web.config bestand. Je maakt simpelweg een Web.Release.config aan met de productiewaarden er in en bij een publish worden deze gebruikt.

Maar de gegevens staan dan dus in een bestandje en zullen nooit zomaar opduiken in een dump van je omgevingsvariabelen.

Daarnaast zou ik graag een andere vorm van authenticatie zien. Geen idee hoe dat zit op Linux, maar op Windows kan ik integrated security gebruiken. Dat betekent dat de user waaronder mijn app draait, automatisch verbindt met SQL server. Ik hoef dus helemaal geen wachtwoord in mijn configuratie te bewaren en Windows regelt dan zelf de authenticatie tussen de user en SQL server (SQL server staat dus in mixed mode en regel daar per Windows account de rechten op de databases).

Geen idee of dit ook met Postgres / MySQL / etc kan en wat het alternatief op Linux is hiervoor, want ik vind wachtwoorden rond laten slingeren iets van de jaren 90. Het hoort niet thuis in 2018

PS
Ik zie dat Postgres iig meerdere authenticatie methoden ondersteunt:
https://www.postgresql.org/docs/9.6/auth-methods.html

MySQL ook:
https://dev.mysql.com/doc...gable-authentication.html

Geen ervaring met Kerberos configureren op Linux, maar dat klinkt iig al veiliger dan gewoon een wachtwoord gebruiken. Ook is het gebruiken van SSL certificaten een oplossing.

PPS
https://help.ubuntu.com/lts/serverguide/kerberos.html.en

Misschien leuk om eens mee te spelen

[ Voor 38% gewijzigd door Lethalis op 07-12-2018 16:16 ]

[Olaf van der Spek]

Barryvdh schreef op vrijdag 7 december 2018 @ 14:25:
[...]


Klopt, daarom wijzen ze daarop in de documentatie en leggen ze uit hoe je bepaalde data kan verbergen. Ik bedoel alleen maar dat het niet de schuld is van de ontwikkelaar als jij de software op een manier gebruikt die zij niet bedoelden.

Documentatie is geen oplossing...

Lethalis schreef op vrijdag 7 december 2018 @ 15:40:
MySQL ook:
https://dev.mysql.com/doc...gable-authentication.html

Pas sinds kort

[ Voor 21% gewijzigd door Olaf van der Spek op 07-12-2018 16:03 ]

[NMe]

Barryvdh schreef op vrijdag 7 december 2018 @ 14:25:
[...]


Klopt, daarom wijzen ze daarop in de documentatie en leggen ze uit hoe je bepaalde data kan verbergen. Ik bedoel alleen maar dat het niet de schuld is van de ontwikkelaar als jij de software op een manier gebruikt die zij niet bedoelden.

Als de standaard is om alles te laten zien en je alleen een werkbare situatie krijgt als je actief dingen aan moet gaan lopen passen is er iets fundamenteel mis.

[Barryvdh]

NMe schreef op vrijdag 7 december 2018 @ 19:58:
[...]

Als de standaard is om alles te laten zien en je alleen een werkbare situatie krijgt als je actief dingen aan moet gaan lopen passen is er iets fundamenteel mis.

Het is prima werkbaar, want het is een (optionele) development tool. Maargoed, sommige mensen haten graag op alles wat met Laravel te maken heeft.

[NMe]

Barryvdh schreef op vrijdag 7 december 2018 @ 20:40:
[...]

Het is prima werkbaar, want het is een (optionele) development tool. Maargoed, sommige mensen haten graag op alles wat met Laravel te maken heeft.

Een optionele tool die standaard mee wordt geleverd, standaard aan staat en standaard deze informatie laat zien. Heel newbievriendelijk ja.

[Olaf van der Spek]

Barryvdh schreef op vrijdag 7 december 2018 @ 20:40:
[...]

Maargoed, sommige mensen haten graag op alles wat met Laravel te maken heeft.

Echt het sterkste argument dat ik in tijden gehoord heb.

[Kalentum]

NMe schreef op vrijdag 7 december 2018 @ 19:58:
[...]

Als de standaard is om alles te laten zien en je alleen een werkbare situatie krijgt als je actief dingen aan moet gaan lopen passen is er iets fundamenteel mis.

Hoe moet je als package maintainer weten in welke environment variabele een wachtwoord zit? Laravel gebruikt DB_PASSWORD, een ander houdt het bij DB_PASS of DB_CONNECTION_STRING ofzo.

@PieterjanDC Ik zie trouwens dat Laravel de mogelijkheid biedt om bepaalde environment variable uit te filteren: zie hier https://laravel.com/docs/...environment-configuration

[Ryur]

Barryvdh schreef op vrijdag 7 december 2018 @ 20:40:
[...]

Het is prima werkbaar, want het is een (optionele) development tool. Maargoed, sommige mensen haten graag op alles wat met Laravel te maken heeft.

Ik wil jou graag bedanken voor alles wat jij met/voor Laravel doet!

Ben pas net 2 weken met Laravel aan het spelen, en kwam al jouw IDE-helper tegen.
(Had toen niet door dat jij een Nederlander was )

[Engineer]

Je kan je laravel map gewoon kopieren, en de public map daarvan symlinken waar je hem hebben wil in je www map.

cp -rp /var/www/laravel-prd /var/www/laravel-dev
chmod -R 777 /var/www/laravel-dev/storage (Als je met meer mensen op 1 server zit kun je misschien beter even de www user uitzoeken en chown ipv chmod 777 doen)
ln -s /var/www/html/laravel-dev /var/www/laravel-dev/public

Je .env even aanpassen zodat de paden daarin ook goed staan.

[ Voor 19% gewijzigd door Engineer op 09-12-2018 11:57 ]

[Verwijderd]

-

[ Voor 110% gewijzigd door Verwijderd op 19-10-2019 16:11 . Reden: Leeg ivm privacy ]

[NMe]

rutgerw schreef op zaterdag 8 december 2018 @ 13:02:
[...]


Hoe moet je als package maintainer weten in welke environment variabele een wachtwoord zit? Laravel gebruikt DB_PASSWORD, een ander houdt het bij DB_PASS of DB_CONNECTION_STRING ofzo.

Het is niet de package maintainer die fout zit maar Laravel wanneer Laravel de keuze maakt voor een package die meegeïnstalleerd wordt. Wat er buiten stock Laravel gebeurt is niet Laravel's fout maar dít is een keuze van de developers zelf en daar hoort een stukje standaardconfig bij, ook (of misschien zelfs juist) op een devmachine. Zie verder de rest van mijn post hieronder want ik zat blijkbaar met wat verouderde info.

Verwijderd schreef op zondag 9 december 2018 @ 12:50:
[...]

Sorry, maar volgens mij is dat al een paar keer onderuit gehaald. Wordt standaard meegeleverd (en dat is een rekbaar begrip maar eigenwijze jongetjes moet je af en toe een win gunnen) maar staat niet standaard aan.

In Laravel 4 kwam het standaard mee ongeacht dev. Uit een oud project van mij:

$ composer why filp/whoops
laravel/framework  v4.2.22  requires  filp/whoops (1.1.*)

Ik zie dat het in Laravel 5 inderdaad niet meer standaard mee komt, of in elk geval niet alleen na een composer require laravel/framework dus dat is inderdaad een stuk beter.

[ Voor 12% gewijzigd door NMe op 09-12-2018 13:43 ]

[Verwijderd]

-

[ Voor 100% gewijzigd door Verwijderd op 19-10-2019 16:11 . Reden: Leeg ivm privacy ]

[NMe]

Verwijderd schreef op zondag 9 december 2018 @ 13:47:
[...]


Laravel 5 kwam uit in februari 2015.

Nou, omdat je het zo zegt toch nog maar eens gekeken. Mijn post van net klopt ook niet, ik installeerde laravel/framework om te kijken wat 5.7 doet en daar kwam het inderdaad niet standaard mee, maar met laravel/laravel dus wel:

$ composer why filp/whoops
laravel/laravel       -       requires (for development)  filp/whoops (^2.0)
nunomaduro/collision  v2.1.1  requires                    filp/whoops (^2.1.4)

En uit de standaard .env:

APP_NAME=Laravel
APP_ENV=local
APP_KEY=base64:W3sKTtZjzn+VO4FnbpYe0XVoIRLH2jYxzsrMHjHgMgU=
APP_DEBUG=true
APP_URL=http://localhost

LOG_CHANNEL=stack

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=homestead
DB_USERNAME=homestead
DB_PASSWORD=secret

Dus mijn eerdere posts staan nog steeds: op de dev-environment komt dit standaard mee en staat het standaard aan, dus hoort het standaard goed geconfigureerd te zijn om in elk geval geen voor Laravel bekende gevoelige gegevens af te drukken. In dit voorbeeld zouden in elk geval APP_KEY en DB_PASSWORD gefilterd moeten worden.

[Chloortablet]

rutgerw schreef op zaterdag 8 december 2018 @ 13:02:
[...]


Hoe moet je als package maintainer weten in welke environment variabele een wachtwoord zit? Laravel gebruikt DB_PASSWORD, een ander houdt het bij DB_PASS of DB_CONNECTION_STRING ofzo.

@PieterjanDC Ik zie trouwens dat Laravel de mogelijkheid biedt om bepaalde environment variable uit te filteren: zie hier https://laravel.com/docs/...environment-configuration

Een van mijn packages die ik standaard in elk project gebruik, past de config on the fly aan om alle variabelen uit de .env te blokkeren in debug_blacklist.

Mocht ik dus een keer zo erg zitten slapen dat én APP_DEBUG nog op true staat én dat de dev dependencies nog meekomen, dan is er in ieder geval nog een plan C.

En daarnaast zie ik ook in een dev-omgeving het nut niet om een hele .env file te tonen...

[Olaf van der Spek]

rutgerw schreef op zaterdag 8 december 2018 @ 13:02:
Hoe moet je als package maintainer weten in welke environment variabele een wachtwoord zit?

Het is 2018.. probeer je nu echt te beweren dat het niet mogelijk is dit op te lossen?

Een (ander) idee is bijvoorbeeld om een .secret-env te hebben waar alles in kan wat 'gevoelig' is.

[Barryvdh]

Het komt inderdaad standaard mee met laravel/laravel (het boilerplate project dat je ook via de installer krijgt), in 4.x zat het idd in de framework requirements, maar nu is het optioneel dus (en standaard voor dev). Of het nodig/handig is, kan je wat van vinden maar 'niet werkbaar' lijkt me wat overdreven. Toen Whoops er een tijd niet in zat, was dat zo ongeveer de meest gehoorde klacht.

Maar ook zonder Whoops/met blacklist moet je debug niet willen aanzetten op je productie omgeving, ook stacktraces kunnen Keys/wachtwoorden bevatten.

Zorg dus altijd voor:
- ontwikkeling op een lokale server, nooit live op de productie omgeving
- APP_DEBUG altijd uit op productie
- geen -dev dependancies op productie. Bij voorkeur gaat live zetten altijd via een script (ofwel pull, migrate, install zonder dev Ed., Of een systeem als Deployer of Envoyer)

Als je dan toch de errors wil bekijken live kan je altijd nog een tail op je log doen, of je logs naar Slack/papertrail etc sturen.

Overigens zijn er wel discussies over, bijvoorbeeld https://github.com/filp/whoops/issues/571
En zou ik zelf ook logischer vinden als ze standaard iets verbergen: https://github.com/laravel/laravel/pull/4788
Of een wildcard optie maken: https://github.com/filp/whoops/issues/610
(Of voor mijn part heel server/env te verbergen)
Maar de algemene setting is dat je debug NOOIT in productie moet gebruiken.

Maar om het meteen te bestempelen alsof het framework onveilig is, is wat mij betreft niet terecht.

[Kalentum]

PerryMr schreef op zondag 9 december 2018 @ 14:04:
En daarnaast zie ik ook in een dev-omgeving het nut niet om een hele .env file te tonen...

Dat Whoops package toont niet in de inhoud van .env maar van $_ENV. Ik neem aan dat .env gesourced wordt in $_ENV?

[Chloortablet]

rutgerw schreef op zondag 9 december 2018 @ 20:06:
[...]


Dat Whoops package toont niet in de inhoud van .env maar van $_ENV. Ik neem aan dat .env gesourced wordt in $_ENV?

Correct, Whoops toont:
- GET Data
- POST Data
- Files
- Cookies
- Session
- Server/Request Data
- Environment Variables

(Bron: http://filp.github.io/whoops/demo/)

[NMe]

Barryvdh schreef op zondag 9 december 2018 @ 16:03:
Maar om het meteen te bestempelen alsof het framework onveilig is, is wat mij betreft niet terecht.

Ik geloof niet dat dat echt de samenvatting was van deze discussie. Ik vind heel veel dingen van Laravel en de meeste daarvan zul jij als iemand die actief aan Laravel bijdraagt niet heel fijn vinden om te horen, maar ik denk niet dat het onveilig is. Wel denk ik dat hier een slechte keuze is gemaakt. Ik bedoel: je hebt helemaal gelijk dat je niet met dev-dependencies of met ingeschakelde debugmodus op een liveserver moet werken, maar zoals ik al vaker heb gezegd in dit topic heeft een deel van de constanten die standaard in .env zitten niks te zoeken in die output, ook niet lokaal.

Zie het een beetje als het nemen van een boottripje. Dat is niet heel verstandig als je niet kan zwemmen dus het is prima om mensen af te raden om op die trip te gaan zonder zwemdiploma, maar dat is nog geen reden om dan de reddingsboeien maar thuis te laten omdat je de aanname maakt dat iedereen je advies opvolgt.

[Barryvdh]

NMe schreef op zondag 9 december 2018 @ 22:56:
[...]

Ik geloof niet dat dat echt de samenvatting was van deze discussie. Ik vind heel veel dingen van Laravel en de meeste daarvan zul jij als iemand die actief aan Laravel bijdraagt niet heel fijn vinden om te horen, maar ik denk niet dat het onveilig is. Wel denk ik dat hier een slechte keuze is gemaakt. [..]

Die samenvatting was ook niet echt als reactie op jou bedoeld (dat was meer de reactie over 'niet werkbaar' vinden), maar over de vraag van TS:

PieterjanDC schreef op donderdag 6 december 2018 @ 10:01:
Nu mijn vraag... Als een MVC framework zo idioot is om de secrets van een een applicatie gewoon te printen in HTML, welke andere idiote security issues kunnen er dan nog naar boven komen? Is het nog verstandig om deze website te blijven hosten of dit framework te blijven gebruiken?

Overigens nog een kleine tip voor mensen die Laravel in productie draaien:

Als je 'php artisan config:cache' draait tijdens je deploy script, zorgt dit ervoor dat je config gecached wordt. Dit is niet alleen sneller, maar dan wordt je .env file ook niet ingeladen in je environment variables, en kunnen ze dus ook niet per ongeluk in logs/dumps etc terecht komen (vanuit je env/server vars iig).
(Dat is ook de reden dat je NOOIT `env('IETS')` mag doen in je code zelf, alleen in de configuratie files.)

[edofso]

Barryvdh schreef op maandag 10 december 2018 @ 10:29:

Overigens nog een kleine tip voor mensen die Laravel in productie draaien:

Als je 'php artisan config:cache' draait tijdens je deploy script, zorgt dit ervoor dat je config gecached wordt. Dit is niet alleen sneller, maar dan wordt je .env file ook niet ingeladen in je environment variables, en kunnen ze dus ook niet per ongeluk in logs/dumps etc terecht komen (vanuit je env/server vars iig).
(Dat is ook de reden dat je NOOIT `env('IETS')` mag doen in je code zelf, alleen in de configuratie files.)

Als je dan bijvoorbeeld in je code ergens een api token gebruikt, wil je deze liever via config('test.api_token'); ophalen? Waar config/test.php -> return ['api_token' => env('API_TOKEN')];?

[Barryvdh]

edofso schreef op maandag 10 december 2018 @ 12:18:
[...]


Als je dan bijvoorbeeld in je code ergens een api token gebruikt, wil je deze liever via config('test.api_token'); ophalen? Waar config/test.php -> return ['api_token' => env('API_TOKEN')];?

Ja precies, altijd je .env waardes gebruiken in je config files. Meestal gebruik ik gewoon config/services.php. Dus als je het in je code nodig hebt is het altijd `config('services.slack.apikey')` en nooit `env('SLACK_API_KEY')`. Want die laatste bestaat dus niet als je config gecached is.

(Al moet je hierbij wel rekening houden dat je geen functies/callbacks kan gebruiken in je config, en dat je handmatig je config opnieuw moet cachen als je iets wijzigt)

[ Voor 13% gewijzigd door Barryvdh op 10-12-2018 13:03 ]

[edofso]

Barryvdh schreef op maandag 10 december 2018 @ 13:00:
[...]

Ja precies, altijd je .env waardes gebruiken in je config files. Meestal gebruik ik gewoon config/services.php. Dus als je het in je code nodig hebt is het altijd `config('services.slack.apikey')` en nooit `env('SLACK_API_KEY')`. Want die laatste bestaat dus niet als je config gecached is.

(Al moet je hierbij wel rekening houden dat je geen functies/callbacks kan gebruiken in je config, en dat je handmatig je config opnieuw moet cachen als je iets wijzigt)

Goed om te weten, ga ik nu even wat code aanpassen, bedankt voor de tip!

[Barryvdh]

Ik heb trouwens even een Pull Request gemaakt voor Whoops, hopelijk maakt dat het iets logischer/makkelijker: https://github.com/filp/whoops/pull/612
Zodat je gewoon *_PASSWORD of * om alles te blokkeren kan doen. Mocht je dat graag willen, kan het geen kwaad om dat te laten weten op Github

[PieterjanDC]

Ik heb gemerkt dat in de .env.example de APP_DEBUG standaard op TRUE staat. Het is dus de bedoeling dat je deze kopieert, maar deze standaardwaarde kun je dus niet standaard laten. Wat is hierover nagedacht zeg...

Het feit dat Whoops enkel in de DevDependencies staat, wil niet zeggen dat het niet op een installatie in productie kan terechtkomen... Zelf als je je vergist en de standaard npm install doet, wordt flip/whoops geïnstalleerd. Dit wil dus zeggen dat je een installatie niet kan porten naar productie door de APP_DEBUG op false te zetten want ja flip/whoops is nog steeds geïnstalleerd en kan dus een beveiligingsrisico vormen.

Hierbij moet ik nog een link naar een artikel toevoegen...
Hacken.io

Hierbij is blijkbaar een geval gevonden waarbij debug uit staat en de environment variabelen TOCH geëxposed werden.
Ja eens één schakel breekt, is onmiddellijk de volledige chain of security kapot. De Laravel ontwikkelaars willen dit blijkbaar niet inzien...

En het blijft nog steeds supereenvoudig om in te breken in iemands netwerk, zoeken naar hosts in dat netwerk en dmv een netstat alle open poorten op iedere host achterhalen. Eens je virus verspreidt geraakt is het supereenvoudig om Laravel websites te zoeken en de kans is groot dat een private server in debug staat.
De Algolia-credentials, Pusher-credentials, Mailgun-credentials, misschien de SQL credentials indien deze dezelfde zijn als in productie, liggen gewoon voor het rapen.
De andere Laravel ontwikkelaars zien hier absoluut geen graten in. Ik kan alleen maar kiezen voor een ander framework waar security wel primeert.

Indien je website werkt in Testomgeving, maar niet in productie, is het direct een heel pak moeilijker natuurlijk om uit te zoeken waar het probleem zit. Sure je kan de logfiles openen en hopen dat hier iets zinvol in staat (indien de log-directory writeable is voor www-data). Maar verder maakt het debuggen in productie een pak moeilijker als je absoluut nooit je website in debug mag zetten in productie. Zoek maar waar het probleem zit dan...

@Barryvdh Ik vind uw voorstel om wildcards toe te laten heel interessant. Kleine sidenote: ik heb al op een andere website gelezen dat het beter is om dingen te whitelisten in plaats van te blacklisten.
Op deze manier moet je expliciet toestaan dat iets vrijgegeven wordt. Dit vond ik ook een heel interessante opmerking... Wanneer er environment variabelen bijkomen in je applicatie worden deze dan by-default niet geëxposed, enkel wanneer je expliciet de configuratie aanpast...

[ Voor 21% gewijzigd door PieterjanDC op 28-12-2018 15:34 ]

[Radiant]

Een website moet om nog veel meer redenen dan dat nooit in debug-mode op een productieserver. Ook een bug is geen reden om het dan maar 'even' aan te zetten.

Een errorhandler zoals Whoops geeft nog veel meer info vrij dan environment variabelen met database-wachtwoorden. Sterker nog, dat zal waarschijnlijk de minst interessante zijn, want DB-servers staan meestal niet naar het internet open.

Een productiesite moet gewoon een nette error geven naar een gebruiker toe en ergens een uitgebreide errorlog opslaan. Daar kan net zoveel info in staan dan als je in je 'whoops'-pagina ziet in een devomgeving.

[PieterjanDC]

Ja dan kan iedereen nog steeds inbreken in je netwerk en gewoon een simpele webrequest sturen naar een staging server... Dat is echt niet moeilijk hoor

[ Voor 11% gewijzigd door PieterjanDC op 28-12-2018 15:47 ]

[Radiant]

Daar gaan al een paar dingen fout:
- een staging-site hoort een aparte db te hebben en aparte credentials
- een staging-site hoort geen livedata in zijn db te hebben
- een staging-site hoort óók geen verbose error messages te geven
- je staging-site is niet of onvoldoende afgesloten voor het publiek
- je netwerk is niet veilig

[PieterjanDC]

een staging-site hoort een aparte db te hebben en aparte credentials

Dat is uiteraard zo

een staging-site hoort geen livedata in zijn db te hebben

Dat is uiteraard niet het geval

een staging-site hoort óók geen verbose error messages te geven

Een testserver geeft error messages, anders is het geen testserver...

je staging-site is niet of onvoldoende afgesloten voor het publiek

Een virus is zo gemaakt en verspreid. Het is een kwestie van tijd vooralleer deze terechtkomt in een netwerk waar een Laravel site gehost wordt.

je netwerk is niet veilig

Niemand kan in mijn netwerk, tenzij natuurlijk iemand een virus verspreidt en mijn zus/een werknemer download dit virus... Firewall rules halen dan niet veel uit.
Op iedere computer zit er natuurlijk een virusscanner, maar ja een virus heeft maar 1 uur nodig om ernstige schade aan te richten, en in het geval van Laravel approx. 20 seconden...

De essentie van de zaak is trouwens dat je nooit een wachtwoord op een webpagina zet...
Indien je niet overtuigd bent hierover: Github discussion

Als ik trouwens wil debuggen van buitenaf op een testserver, of als ik een vpn server zou gebruiken om te testen, dan kan ik dus op mijn kin kloppen...

[ Voor 112% gewijzigd door PieterjanDC op 28-12-2018 16:12 ]

[Radiant]

Ga je je code dan ook online aanpassen? Op een stagingserver hoor je ook niet te ontwikkelen Een dev-omgeving lokaal opzetten is een fluitje van een cent, dan kan je daar ook zoveel verbose errors weergeven als je zelf wil.

[PieterjanDC]

Daarvoor hebben ze SSH uitgevonden. En lokale dev zoals Vagrant/Homestead hebben nogal wat beperkingen.

[ Voor 50% gewijzigd door PieterjanDC op 28-12-2018 16:17 ]

[NMe]

PieterjanDC schreef op vrijdag 28 december 2018 @ 15:53:
Een testserver geeft error messages, anders is het geen testserver...

Staging != test. Althans, het is een ander soort testing. Op staging ga je acceptatietesten, en daar ga je dus identieke config (maar niet identieke data, uiteraard) draaien als je in productie zou doen. Inclusief gebrek aan foutmeldingen dus. Daar staat tegenover dat een échte testserver (die dus intern is) nooit aan het internet hoort te hangen, want die kan inderdaad gevoelige gegevens vrijgeven, ook op een testsysteem.

Een virus is zo gemaakt en verspreid. Het is een kwestie van tijd vooralleer deze terechtkomt in een netwerk waar een Laravel site gehost wordt.

Ik vind dat nogal een makkelijke gevolgtrekking in een topic waar je nota bene afgeeft op de beveiligingsconsequenties van een rare keuze in Laravel. Het is simpel zat om virussen af te houden, en dan nog is het bestaan van virussen nog geen excuus om dan maar foutmeldingen te tonen op een via internet benaderbare server.

De essentie van de zaak is trouwens dat je nooit een wachtwoord op een webpagina zet...
Indien je niet overtuigd bent hierover: Github discussion

Ik ben het met je eens, maar jezelf in fullcaps als "bron" aanhalen slaat nergens op, en zoals ze ook daar al zeggen ben je niet bepaald op een normale manier je gelijk aan het halen daar. Laravel is sowieso lang niet je enige risico op dat vlak, PDO kan er ook wat van.

Als ik trouwens wil debuggen van buitenaf op een testserver, of als ik een vpn server zou gebruiken om te testen, dan kan ik dus op mijn kin kloppen...

Debuggen op een server die aan het internet hangt doe je niet met APP_DEBUG op true, niet met display_errors op true, niet met error_reporting or E_ALL. Ook niet voor eventjes. Als je wil debuggen op een server die aan het internet hangt kun je hooguit dit soort truukjes uithalen:

PHP:

if ($_SERVER['REMOTE_ADDR'] == 'jouw-ip') {
    ini_set('display_errors', 1);
    ini_set('display_startup_errors', 1);
    error_reporting(-1);
}

Maar ook dat is in theorie riskant. Idealiter zorg je voor goede logging en zorg je ervoor dat stack traces per mail naar je toe gestuurd worden als er een error optreedt. 9 van de 10 keer hoef je dan niet eens te je code te debuggen.

PieterjanDC schreef op vrijdag 28 december 2018 @ 16:15:
Daarvoor hebben ze SSH uitgevonden. En lokale dev zoals Vagrant/Homestead hebben nogal wat beperkingen.

Zoals? Je hoeft verder ook niet per se Vagrant of Homestead te gebruiken, je mag ook gewoon zelf Apache/Nginx, PHP en MySQL/MariaDB installeren.

[PieterjanDC]

Ik raad u toch aan om eens deze link van hacken.io te openen...

Het gaat over een geval waarbij APP_DEBUG=FALSE. En ja toch werd de Whoops page getoond...
WHOOPS

Eén accidentiele fout door de Laravel ontwikkelaars, één composer update en al je credentials liggen gewoon op de straat...

[ThomasG]

PieterjanDC schreef op vrijdag 28 december 2018 @ 16:56:
Ik raad u toch aan om eens deze link van hacken.io te openen...

Het gaat over een geval waarbij APP_DEBUG=FALSE. En ja toch werd de Whoops page getoond...
WHOOPS

Eén accidentiele fout door de Laravel ontwikkelaars, één composer update en al je credentials liggen gewoon op de straat...

Misschien dat ik jouw gelinkte artikel niet goed lees, maar daar gaat het over gevallen waarbij debug mode aan staan op een production server. Dus dat heeft niets te maken met jouw bewering dat er een "Whoops" pagina werd getoont terwijl debug mode uit stond.

Daarnaast kan er altijd een security lek zijn ingeslopen in dependencies. Daarom lees je alijd de changelog voordat je iets update, en ga je dat natuurlijk eerst testen. Wat natuurlijk niet wegneemt dat de wachtwoorden nooit in de foutmelding moeten staan, sterker nog ze zouden na gebruik meteen uit het geheugen gehaald moeten worden. Dat is natuurlijk een fout.

Ik vind het toch wel een beetje grappig. Je loopt allemaal redenen te verzinnen waarom separate test servers, dependencies, e.d. onveilig zouden zijn. Terwijl je het zelf de normaalste zaak van de wereld vind als je via SSH op een productieserver code gaat lopen aanpassen

[Radiant]

NMe schreef op vrijdag 28 december 2018 @ 16:48:
[...]

Zoals? Je hoeft verder ook niet per se Vagrant of Homestead te gebruiken, je mag ook gewoon zelf Apache/Nginx, PHP en MySQL/MariaDB installeren.

Laravel maakt het ook gemakkelijk om PHPs interne webserver te gebruiken voor ontwikkeldoeleinden, dan heb je zelfs geen Apache/Nginx nodig.

code:

php artisan serve

En uiteraard is dat standaard alleen toegankelijk vanaf localhost, wel zo veilig

[NMe]

PieterjanDC schreef op vrijdag 28 december 2018 @ 16:56:
Ik raad u toch aan om eens deze link van hacken.io te openen...

En waar op die pagina staat iets dat tegenspreekt wat ik net zei?

Radiant schreef op vrijdag 28 december 2018 @ 18:18:
[...]

Laravel maakt het ook gemakkelijk om PHPs interne webserver te gebruiken voor ontwikkeldoeleinden, dan heb je zelfs geen Apache/Nginx nodig.

code:

php artisan serve

En uiteraard is dat standaard alleen toegankelijk vanaf localhost, wel zo veilig

Ik vind dat juist niet fijn, vooral omdat ik nogal vaak tussen projecten moet switchen op een dag. Soms moet ik zelfs acuut overschakelen naar een ander project. Ik wil dan gewoon naar de site die ik nodig heb kunnen browsen zonder eerst servers te moeten stoppen en andere te moeten starten. Dan spendeer ik liever even eenmalig dat halve uurtje om een echte server op te starten en er nooit meer naar te hoeven omkijken.

[ Voor 55% gewijzigd door NMe op 28-12-2018 18:43 ]

[Olaf van der Spek]

Radiant schreef op vrijdag 28 december 2018 @ 18:18:
En uiteraard is dat standaard alleen toegankelijk vanaf localhost, wel zo veilig

Sinds wanneer is localhost veilig?

[Matis]

Olaf van der Spek schreef op zaterdag 29 december 2018 @ 15:59:
Sinds wanneer is localhost veilig?

Daarnaast werkt het niet als je vagrant of docker gebruikt, want dan kom je niet van localhost.

[Groax]

NMe schreef op vrijdag 28 december 2018 @ 18:40:
[...]

En waar op die pagina staat iets dat tegenspreekt wat ik net zei?

[...]

Ik vind dat juist niet fijn, vooral omdat ik nogal vaak tussen projecten moet switchen op een dag. Soms moet ik zelfs acuut overschakelen naar een ander project. Ik wil dan gewoon naar de site die ik nodig heb kunnen browsen zonder eerst servers te moeten stoppen en andere te moeten starten. Dan spendeer ik liever even eenmalig dat halve uurtje om een echte server op te starten en er nooit meer naar te hoeven omkijken.

https://stackoverflow.com...for-php-artisan-php-serve

Kijk hier even naar. Je kan meerdere projecten tegelijkertijd draaien. misschien de IP adressen die je eraan geeft in je HOST file een naam geven voor het gemak?

[NMe]

moese schreef op zaterdag 29 december 2018 @ 23:51:
[...]


https://stackoverflow.com...for-php-artisan-php-serve

Kijk hier even naar. Je kan meerdere projecten tegelijkertijd draaien. misschien de IP adressen die je eraan geeft in je HOST file een naam geven voor het gemak?

Mja, of ik stel één keer Apache goed in en heb nooit meer omkijken naar poorten, hostnames en hostfiles lokaal...

[Groax]

NMe schreef op zondag 30 december 2018 @ 00:07:
[...]

Mja, of ik stel één keer Apache goed in en heb nooit meer omkijken naar poorten, hostnames en hostfiles lokaal...

Kan ook maar ik werk vaak vanuit andere plekken dan een Apache WWW folder en ik zit vast geroest aan de Artisan serve functie

[NMe]

moese schreef op zondag 30 december 2018 @ 01:42:
[...]

Kan ook maar ik werk vaak vanuit andere plekken dan een Apache WWW folder en ik zit vast geroest aan de Artisan serve functie

Het zal Apache worst wezen of 'ie loopt te serveren uit /var/www/* of ~/projects/*.

[PieterjanDC]

Verwijderd schreef op zondag 9 december 2018 @ 12:50:
[...]

Sorry, maar volgens mij is dat al een paar keer onderuit gehaald. Wordt standaard meegeleverd (en dat is een rekbaar begrip maar eigenwijze jongetjes moet je af en toe een win gunnen) maar staat niet standaard aan.

Heb ik al gezegd dat zelf de .env.example hier "standaard" niet op ingesteld is...
https://github.com/laravel/laravel/blob/master/.env.example

Zelf als je "beweert" dat Laravel standaard goed ingesteld is, kijk naar het voorbeeld.
Uiteraard moet je dit aanpassen op een productie, daar ben ik het met je eens.
Maar het is zeker al niet standaard juist ingesteld.

@Barryvdh
Het idee van de wildcard debug_blacklist klinkt als muziek in mijn oren. Hopelijk wordt de config/app.php dan standaard hiermee aangepast naar:

'debug_blacklist' => [
'*_PASS',
'*_PASSWORD',
'*_KEY',
]

Interessanter nog zou zijn om een debug_whitelist te gebruiken. Hierdoor worden de nieuwe variabelen die aan de .env file toegevoegd worden by-default verborgen. Sommigen beweren dat het beter is te whitelisten dan te blacklisten... Maar met wildcards kan je IMO ook al ongeveer hetzelfde effect bekomen.

Het mag dan al zijn dat een virus in je netwerk terechtkomt en een devserver vindt, hij kan toch al niet je service-account-passwords aflezen van de html-pagina. E-mailadressen voor deze accounts zijn minder belangrijjk om te verbergen.

Of het kan natuurlijik ook zijn dat er per ongeluk (en ja ik geloof dat dat wel eens kan) een bug in de Laravel-repository terechtkomt waardoor de Whoops-page getoond wordt terwijl dat APP_DEBUG feitelijk op FALSE staat.
https://www.google.com/am...ode-enabled%3fhs_amp=true

Maar dan is de chain of security tenminste niet kapot en zal de wildcard debug_blacklist nog kunnen verhinderen dat deze in de HTTP-response terechtkomt.

moese schreef op vrijdag 7 december 2018 @ 14:05:
Ik heb niet alles gelezen maar als je in je .env file de regel (APP_DEBUG) op FALSE zet moet dit de wachtwoorden van je beschermen. sla ook al je wachtwoorden op in je .env file. hier zijn ze 'veilig'

zorg ook dat je wachtwoorden niet in controllers, models of views zet want je gaat ze zien... misschien ook error handling uit zetten op je server?

Dat "zou" moeten, maar in het verleden werd al bewezen dat dit niet altijd zo geweest is...
Zie link

Barryvdh schreef op vrijdag 7 december 2018 @ 10:07:
[...]

Ps. 2, als je op begint te schreeuwen in je Issue, zou ik je ook niet meer helpen: https://github.com/laravel/framework/issues/26750

Ik had dit al eerder op Laracasts gevraagd. Daar werd mijn vraag onmiddellijk naar de prullenmand gestuurd.
Alle verantwoordelijkheid wordt in directe lijn naar de eindontwikkelaar gestuurd en Laravel bleek hier geen verantwoordelijkheid te willen dragen. Poor default settings, ... Het antwoord is onmiddellijk dat je nooit debug aan moet hebben staan public (ok, hier ben ik het mee eens), maar dit belet niet dat iemand je netwerk hackt en onmiddellijk alle environment variables kan opvragen via het minst beveiligde protocol in de web development. Zelf als bewezen is dat de Whoops-page tevoorschijn kan komen bij APP_DEBUG=FALSE, wordt hier nog steeds geen graten in gezien.

Je stelt een vraag of geeft een suggestie en krijgt direct het deksel op de neus. Vervolgens zoek je op internet, vind je forumposts van mensen die exact hetzelfde zeggen: Plaats nooit een wachtwoord in een HTTP-response, onmiddellijk 30 resultaten en het antwoord hierop is steeds, steeds It's not us, we're innocent.
Dit geeft al onmiddellijk de blijk dat de ontwikkelaars achter dit project niet van plan zijn om alle security holes in hun framework zo goed mogelijk dicht te maken. Zonde want Laravel is qua performantie superefficiënt (veel efficiënter dan ASP.NET of zelfs andere PHP-frameworks). Vervolgens krijg je op GitHub dezelfde reacties van de project-beheerders. Dan kun je wel denken dat de webapp-developers hier niet echt happy mee zijn toch?

Ik begrijp niet waarom men zo losbandig kan omspringen met het exposen van secret values via HTTP (zoals ik al zei het minst beveiligde protocol in web development). Bij SSH of FTP moet je een wachtwoord opgeven vooraleer je kan verbinden, een HTTP-request is zo gestuurd en duurt maar 20 ms.

[ Voor 48% gewijzigd door PieterjanDC op 01-01-2019 12:24 . Reden: debug_whitelist ipv debug_blacklist ]

[Barryvdh]

PieterjanDC schreef op dinsdag 1 januari 2019 @ 11:02:
[...]


Of het kan natuurlijik ook zijn dat er per ongeluk (en ja ik geloof dat dat wel eens kan) een bug in de Laravel-repository terechtkomt waardoor de Whoops-page getoond wordt terwijl dat APP_DEBUG feitelijk op FALSE staat.
https://www.google.com/am...ode-enabled%3fhs_amp=true

Er staat dit als reactie:

The reason for the information leak was a bug in the handling of error events in the web app, which caused the web app to act as it was in debug mode (which it wasn't configured to be).

Dus dit staat uberhaupt los van APP_DEBUG wel/niet standaard enabled. Hier gaat het er om dat:
- De ontwikkelaars dus Whoops geinstalleerd hadden op productie (itt alleen in je composer dev requirements)
- APP_DEBUG uit stond (correct)
- Maar ze zelf in hun eigen code, toch Whoops triggeren.

Dat is niet 'per ongeluk', dat is gewoon bewust (verkeerd) gedaan zoals ik het lees..

[xh3adshotx]

PieterjanDC schreef op dinsdag 1 januari 2019 @ 11:02:
[...]


Heb ik al gezegd dat zelf de .env.example hier "standaard" niet op ingesteld is...
https://github.com/laravel/laravel/blob/master/.env.example

Zelf als je "beweert" dat Laravel standaard goed ingesteld is, kijk naar het voorbeeld.
Uiteraard moet je dit aanpassen op een productie, daar ben ik het met je eens.
Maar het is zeker al niet standaard juist ingesteld.

@Barryvdh
Het idee van de wildcard debug_blacklist klinkt als muziek in mijn oren. Hopelijk wordt de config/app.php dan standaard hiermee aangepast naar:

'debug_blacklist' => [
'*_PASS',
'*_PASSWORD',
'*_KEY',
]

Interessanter nog zou zijn om een debug_whitelist te gebruiken. Hierdoor worden de nieuwe variabelen die aan de .env file toegevoegd worden by-default verborgen. Sommigen beweren dat het beter is te whitelisten dan te blacklisten... Maar met wildcards kan je IMO ook al ongeveer hetzelfde effect bekomen.

Het mag dan al zijn dat een virus in je netwerk terechtkomt en een devserver vindt, hij kan toch al niet je service-account-passwords aflezen van de html-pagina. E-mailadressen voor deze accounts zijn minder belangrijjk om te verbergen.

Of het kan natuurlijik ook zijn dat er per ongeluk (en ja ik geloof dat dat wel eens kan) een bug in de Laravel-repository terechtkomt waardoor de Whoops-page getoond wordt terwijl dat APP_DEBUG feitelijk op FALSE staat.
https://www.google.com/am...ode-enabled%3fhs_amp=true

Maar dan is de chain of security tenminste niet kapot en zal de wildcard debug_blacklist nog kunnen verhinderen dat deze in de HTTP-response terechtkomt.


[...]


Dat "zou" moeten, maar in het verleden werd al bewezen dat dit niet altijd zo geweest is...
Zie link


[...]


Ik had dit al eerder op Laracasts gevraagd. Daar werd mijn vraag onmiddellijk naar de prullenmand gestuurd.
Alle verantwoordelijkheid wordt in directe lijn naar de eindontwikkelaar gestuurd en Laravel bleek hier geen verantwoordelijkheid te willen dragen. Poor default settings, ... Het antwoord is onmiddellijk dat je nooit debug aan moet hebben staan public (ok, hier ben ik het mee eens), maar dit belet niet dat iemand je netwerk hackt en onmiddellijk alle environment variables kan opvragen via het minst beveiligde protocol in de web development. Zelf als bewezen is dat de Whoops-page tevoorschijn kan komen bij APP_DEBUG=FALSE, wordt hier nog steeds geen graten in gezien.

Je stelt een vraag of geeft een suggestie en krijgt direct het deksel op de neus. Vervolgens zoek je op internet, vind je forumposts van mensen die exact hetzelfde zeggen: Plaats nooit een wachtwoord in een HTTP-response, onmiddellijk 30 resultaten en het antwoord hierop is steeds, steeds It's not us, we're innocent.
Dit geeft al onmiddellijk de blijk dat de ontwikkelaars achter dit project niet van plan zijn om alle security holes in hun framework zo goed mogelijk dicht te maken. Zonde want Laravel is qua performantie superefficiënt (veel efficiënter dan ASP.NET of zelfs andere PHP-frameworks). Vervolgens krijg je op GitHub dezelfde reacties van de project-beheerders. Dan kun je wel denken dat de webapp-developers hier niet echt happy mee zijn toch?

Ik begrijp niet waarom men zo losbandig kan omspringen met het exposen van secret values via HTTP (zoals ik al zei het minst beveiligde protocol in web development). Bij SSH of FTP moet je een wachtwoord opgeven vooraleer je kan verbinden, een HTTP-request is zo gestuurd en duurt maar 20 ms.

Buiten dat je in productie ALTIJD APP_DEBUG op "false" moet hebben (testen/editten doe je maar lekker in een dev/test omgeving), installeer je op een productie omgeving NOOIT de dev dependencies. Als je beide dingen netjes doet zal je de "whoops" pagina nooit krijgen omdat "APP_DEBUG" false is én mocht dat mis gaan kan de "whoops" pagina niet getoond worden omdat die niet bestaat (package is er niet).


Als iemand je netwerk hacked boeit het ook weinig toch? Als je dev netwerk gehacked word kan iemand bij test/dummy data - veel plezier ermee... Als iemand je productie netwerk hacked heb je grotere problemen dan de "whoops" pagina (die dus niet bestaat omdat het package mist, die moeten ze dan zelf installeren en dan kunnen ze wel "leukere" dingen doen)...

[NMe]

PieterjanDC schreef op dinsdag 1 januari 2019 @ 11:02:
[...]

Ik begrijp niet waarom men zo losbandig kan omspringen met het exposen van secret values via HTTP

Ik begrijp inderdaad ook niet waarom je je dev dependencies op productie installeert en bovendien ook blijkbaar je config niet naloopt. Ik ben ook geen fan van Laravel's keuze om maar gewoon alles af te drukken (zie hierboven) maar om daar te komen moet je zoals nou al zo vaak gezegd in dit topic twee verschillende fouten maken. Je moet de je env-variabelen verkeerd instellen en je moet je dev dependencies in productie draaien. Voor dat eerste blijf je maar naar de het voorbeeldbestand wijzen, maar dat slaat nergens op. Er is een reden dat dat bestand .env.example heet en niet .env. Als jij het niet zelf kan bedenken dat je die file op productie moet nalopen dan kun je beter maar ophouden met programmeren, want dan ga je nog tegen héél veel dingen aan lopen. Hetzelfde geldt voor het installeren van dev dependencies.

Je bent overal tegenaan aan het schoppen en deels heb je daar inmiddels uiteindelijk gelijk in gekregen, maar feit blijft dat je zelf ronduit dom bezig bent.

[Chloortablet]

NMe schreef op zondag 30 december 2018 @ 00:07:
[...]

Mja, of ik stel één keer Apache goed in en heb nooit meer omkijken naar poorten, hostnames en hostfiles lokaal...

Aanrader: gewoon lokaal Apache, PHP en MySQL draaien en met Acrylic DNS Proxy alle *.local linken aan 127.0.0.1. Daarna inderdaad mod_vhost_alias juist instellen en elke nieuwe folder in een map wordt automatisch een nieuw "domein".

code:

<Virtualhost *:80>
    VirtualDocumentRoot "C:\Users\****\Server\%-2+"
    ServerName vhosts.local
    ServerAlias *.local
    UseCanonicalName Off
    ErrorLog "C:\Users\****\Server\vhosts-error_log"

    <Directory "C:\Users\****\Server\*">
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Order Deny, Allow
        Deny from all
        Allow from 127.0.0.1 ::1
        Allow from localhost
        Allow from 192.168
        Allow from 10
        Satisfy Any
    </Directory>
</Virtualhost>

[PieterjanDC]

Als jij het niet zelf kan bedenken dat je die file op productie moet nalopen dan kun je beter maar ophouden met programmeren, want dan ga je nog tegen héél veel dingen aan lopen.

Dat zei ik dus idd...

Maar verder is de essentie van het verhaal dus:
local dev:

code:

composer install

production:

code:

composer install --no-dev

[mamorunl]

Ik wil toch graag op 1 ding inhaken: Je noemt steeds 'een virus' die het blootlegt of 'infiltreert in je netwerk'. Waarom zou datzelfde virus niet gewoon een .env bestand uitlezen en opsturen? Waarom zou het een bestand publiekelijk maken in plaats van naar de auteurs van het virus opsturen en zo de wachtwoorden geven?

Alles wat ik hier lees in dit topic is allemaal in één hokje te plaatsen: goede configuratie. De fouten van een .env buiten je public_html zetten of van debug mode aan laten staan zijn nou niet echt fouten die je aan de devs kunt toewijzen.

[codeclap]

PieterjanDC schreef op dinsdag 1 januari 2019 @ 18:19:
[...]

Dat zei ik dus idd...

Maar verder is de essentie van het verhaal dus:
local dev:

code:

composer install

production:

code:

composer install --no-dev

Maar.. Dit staat toch gewoon in de documentatie, samen met nog wat best practices..?

https://laravel.com/docs/5.7/deployment

When deploying to production, make sure that you are optimizing Composer's class autoloader map so Composer can quickly find the proper file to load for a given class:

composer install --optimize-autoloader --no-dev

[mc-koenoe]

Respect voor de reactie van de Laravel contributors op dat belachelijke Github issue. Beetje meer waardering voor het werk van open source developers is wel op zijn plaats. En zoals al is geopperd in dit topic, mocht je het ergens niet mee eens zijn, doe een PR en ga op die manier de discussie met ze aan.

[xh3adshotx]

Nog een paar aanvullingen aangezien ik nu meer tijd heb:

PieterjanDC schreef op dinsdag 1 januari 2019 @ 11:02:
Heb ik al gezegd dat zelf de .env.example hier "standaard" niet op ingesteld is...
https://github.com/laravel/laravel/blob/master/.env.example

Zelf als je "beweert" dat Laravel standaard goed ingesteld is, kijk naar het voorbeeld.
Uiteraard moet je dit aanpassen op een productie, daar ben ik het met je eens.
Maar het is zeker al niet standaard juist ingesteld.

Aangezien dit een voorbeeld ".env" is (check de naam: example = voorbeeld) is het prima standaard ingesteld. De applicatie zal immers eerst op een dev(eloper) omgeving ontwikkeld worden waar gedetaileerde exceptions handig zijn en tijd kunnen besparen. Als je de documentatie erbij pakt staat bij de configuratie letterlijk:

quote: https://laravel.com/docs/...environment-configuration

Your .env file should not be committed to your application's source control, since each developer / server using your application could require a different environment configuration. Furthermore, this would be a security risk in the event an intruder gains access to your source control repository, since any sensitive credentials would get exposed.

Met andere woorden: het is de bedoeling om de .env aan te passen voor elke omgeving die je hebt. Elke zichzelf respecterende developer die meer doet dan simpelweg copy&paste zal in het bestand zien dat bepaalde debug variable aan/uit gezet kunnen worden en/of opzoeken wat dingen betekenen.

PieterjanDC schreef op dinsdag 1 januari 2019 @ 11:02:
@Barryvdh
Het idee van de wildcard debug_blacklist klinkt als muziek in mijn oren. Hopelijk wordt de config/app.php dan standaard hiermee aangepast naar:

'debug_blacklist' => [
'*_PASS',
'*_PASSWORD',
'*_KEY',
]

Interessanter nog zou zijn om een debug_whitelist te gebruiken. Hierdoor worden de nieuwe variabelen die aan de .env file toegevoegd worden by-default verborgen. Sommigen beweren dat het beter is te whitelisten dan te blacklisten... Maar met wildcards kan je IMO ook al ongeveer hetzelfde effect bekomen.

Dit is grotendeels persoonlijke voorkeur. Zelf ben ik het er niet helemaal mee eens, het kan zeker handig zijn om deze data op de dev(eloper) omgeving te printen. Zelf werk ik in een omgeving met zeer stricte beveiligingspolicies en ondanks dat onze dev(eloper) omgevingen geen productie data bevatten (waar wij ook niet bij kunnen) verlopen bijna alle wachtwoorden na een bepaalde tijd. Als ik het wachtwoord gewijzigd heb vind ik het best handig dat een exceptie pagina de wachtwoorden weergeeft die de applicatie gebruikt - zo zie ik snel wat fout gaat zonder dat ik tijden aan het zoeken ben.

Tevens maakt het helemaal niets uit dat dit wachtwoord over het "minst beveiligde protocol in de webdevelopment" gaat. Als het goed is draait je dev(eloper) omgeving toch lokaal of op een eigen server en worden er geen productie wachtwoorden gebruikt. In mijn geval zal het wachtwoord over https van localhost naar localhost gaan waarbij de poorten zijn afgeschermd door de firewall (echt alleen localhost bereikbaar).

PieterjanDC schreef op dinsdag 1 januari 2019 @ 11:02:
Het mag dan al zijn dat een virus in je netwerk terechtkomt en een devserver vindt, hij kan toch al niet je service-account-passwords aflezen van de html-pagina. E-mailadressen voor deze accounts zijn minder belangrijjk om te verbergen.

Als het goed is staat er totaal geen gevoelige data op je dev-omgeving. Als dat wel zo is zijn de e-mailadressen net zo belangrijk. Anders heb je immers een (klein) data lek. Wanneer een virus in jouw netwerk weet door te dringen heb je een groter probleem dan een "whoops" pagina die ".env" gegevens print. Waarom zou dat virus niet gewoon de ".env" uitlezen of andere bestanden? Rechtstreeks voor de database server gaan?

PieterjanDC schreef op dinsdag 1 januari 2019 @ 11:02:
Of het kan natuurlijik ook zijn dat er per ongeluk (en ja ik geloof dat dat wel eens kan) een bug in de Laravel-repository terechtkomt waardoor de Whoops-page getoond wordt terwijl dat APP_DEBUG feitelijk op FALSE staat.
https://www.google.com/am...ode-enabled%3fhs_amp=true

Heb je de link zelf ook gelezen? Die developer heeft zelf de "whoops" pagina op een of andere hacky manier getriggered en de dev(eloper) dependencies op de prod(uction) omgeving gezet:

quote: Murphy's law

If you make something idiot-proof, someone will just make a better idiot

PieterjanDC schreef op dinsdag 1 januari 2019 @ 11:02:
Maar dan is de chain of security tenminste niet kapot en zal de wildcard debug_blacklist nog kunnen verhinderen dat deze in de HTTP-response terechtkomt.

Als de chain of security zo belangrijk is neem ik aan dat je grondig de documentatie leest van de producten/libraries/frameworks die je gebruikt en daar de best-practices van overneemt. Als je "app_debug" op "true" zet en de developer dependencies in productie gebruikt is de chain of security niet belangrijk (genoeg) om je druk over te maken.

PieterjanDC schreef op dinsdag 1 januari 2019 @ 11:02:
Ik had dit al eerder op Laracasts gevraagd. Daar werd mijn vraag onmiddellijk naar de prullenmand gestuurd.
Alle verantwoordelijkheid wordt in directe lijn naar de eindontwikkelaar gestuurd en Laravel bleek hier geen verantwoordelijkheid te willen dragen. Poor default settings, ... Het antwoord is onmiddellijk dat je nooit debug aan moet hebben staan public (ok, hier ben ik het mee eens), maar dit belet niet dat iemand je netwerk hackt en onmiddellijk alle environment variables kan opvragen via het minst beveiligde protocol in de web development. Zelf als bewezen is dat de Whoops-page tevoorschijn kan komen bij APP_DEBUG=FALSE, wordt hier nog steeds geen graten in gezien.

Tja, alles kan tevoorschijn komen als de developer incompetent is. Laten we gewoon maar de hele ".env" weghalen aangezien een "developer" ook gewoon de inhoud van die file kan weergeven in z'n foutmelding omdat dat lekker makkelijk is. Daarnaast snap ik prima dat Laravel geen verantwoordelijkheid wil dragen voor developers die niet instaat zijn of tijd willen investeren om documentatie te lezen.

PieterjanDC schreef op dinsdag 1 januari 2019 @ 11:02:
Je stelt een vraag of geeft een suggestie en krijgt direct het deksel op de neus. Vervolgens zoek je op internet, vind je forumposts van mensen die exact hetzelfde zeggen: Plaats nooit een wachtwoord in een HTTP-response, onmiddellijk 30 resultaten en het antwoord hierop is steeds, steeds It's not us, we're innocent.
Dit geeft al onmiddellijk de blijk dat de ontwikkelaars achter dit project niet van plan zijn om alle security holes in hun framework zo goed mogelijk dicht te maken. Zonde want Laravel is qua performantie superefficiënt (veel efficiënter dan ASP.NET of zelfs andere PHP-frameworks). Vervolgens krijg je op GitHub dezelfde reacties van de project-beheerders. Dan kun je wel denken dat de webapp-developers hier niet echt happy mee zijn toch?

Was die vraag op dezelfde manier gesteld als je GitHub isssue? Daarnaast vind ik 30 resultaten op internet niet zo heel erg veel. Dat je nooit een wachtwoord in een HTTP-response plaatst klopt voor productie. Bij dev-omgevingen kan je andere regels hanteren om het proces te versnellen (zie mijn voorbeeld hierboven) mits je het goed afhandeld. Dat is in dit geval gebeurd (app_debug & dev dependencies).

PieterjanDC schreef op dinsdag 1 januari 2019 @ 11:02:
Ik begrijp niet waarom men zo losbandig kan omspringen met het exposen van secret values via HTTP (zoals ik al zei het minst beveiligde protocol in web development). Bij SSH of FTP moet je een wachtwoord opgeven vooraleer je kan verbinden, een HTTP-request is zo gestuurd en duurt maar 20 ms.

"Secret values" hoe secret kan een secret value van een dev-omgeving zijn? En als de chain of security zo belangrijk is zou ik zeker geen FTP gebruiken. Dat is in feiten de HTTP van file transfer waarbij je wachtwoord PLAIN TEXT over de verbinding gaat.

Aanvullend op bovenstaande heb ik geen idee hoe je erbij komt dat Laravel sneller is dan ASP.net (Core) maar het tegenovergestelde is, net als bij de rest van je aannamens, waar.

Nog een stukje constructief:

Als beveiliging zo belangrijk is voor je omgeving kan je deployment altijd automatiseren waarbij gedeployed word naar een nieuwe (virtuele) host. Op de host kan je vervolgens de health status checken en basale tests uitvoeren (exception triggeren waarbij de response word gevalideerd bijvoorbeeld). Pas als dat succesvol verloopt én iemand bevestigd de deployment nogmaals switch je, zonder down-time, de live omgeving met de nieuwe deployment. Vervolgens kan je nog een stukje zekerheid toevoegen door een reverse-proxy te gebruiken die alle error pagina's vervangt met een eigen error pagina.

[ Voor 3% gewijzigd door xh3adshotx op 01-01-2019 19:30 ]

[PatrickH89]

Met alle respect voor de constructieve discussie in deze thread: OP moet zich realiseren dat hij een hoop stampij maakt om niets. Laravel is een framework voor developers, niet voor mensen die alleen Wordpress installers kunnen hanteren.
Met andere woorden, het hoeft niet volledig fool proof te zijn (vooral omdat dit helemaal niet kan) en je moet meerdere dingen niet op de juiste manier doen om deze problemen te ervaren (dev dependencies installeren én debug aanzetten op productie). Dit lijkt me voor een developer toch fool proof genoeg. Verder is het gewoon je eigen fout om de documentatie totaal niet te lezen beyond het maken van een Laravel project.

Daarbij komt nog eens dat de manier waarop je dit probeert door te drammen buiten alle perken is. Zelfs als je gehinderd werd door kennis van zaken zou niemand in de Laravel community luisteren (en terecht) naar je punten. Je hebt in deze thread eigenlijk nog meer bereikt (Barryvdh) dan je had moeten bereiken op basis van deze posts.

[ Voor 6% gewijzigd door PatrickH89 op 02-01-2019 11:26 ]

[PieterjanDC]

hoe secret kan een secret value van een dev-omgeving zijn?

Als je met mailgun of sparkpost of Algolia werkt, is de kans groot dat je dezelfde account wilt gebruiken... Indien niet dan is dit OK maar van de 200.000 ontwikkelaars zullen er toch wel 40.000 zijn die dit doen.

Het kan zeker handig zijn om deze data op de dev(eloper) omgeving te printen

Als je dit echt wil, en je bent bereid het risico te lopen dat iemand al je wachtwoorden steelt en de accounts gebruikt waar jij voor betaalt, dan kun je steeds gewoon de config-file aanpassen. Security by default vind ik toch belangrijker dan luisteren naar een ontwikkelaar die te lui is om gewoon met één simpele klik zijn .env-file te openen en zijn wachtwoord dat hij dagelijks gebruikt hierin af te lezen. Maar het is natuurlijk hoe je het bekijkt hé.

Tevens maakt het helemaal niets uit dat dit wachtwoord over het "minst beveiligde protocol in de webdevelopment" gaat

Nee, echt? Ik ken zelfs geen websites waarop je je profiel kan aanpassen waarop staat "Dit is je wachtwoord, wil je dit wachtwoord wijzigen?". Technisch is dit uiteraard zelf niet mogelijk (read bcrypt), maar er is dus zelfs geen website in de wereld die het in zijn hoofd haalt om een gebruiker zijn wachtwoord in een HTTP-response te printen. Laat staan een SQL-wachtwoord.
En je vertrouwt enkel en alleen op je firewall dat deze alles gaat tegenhouden? Wat met je eigen computer? Gaat een virus die slechts 20 ms nodig heeft om een webrequest naar een testserver in je netwerk te sturen ook tegengehouden worden? Of misschien de computer van je zus?

Waarom zou dat virus niet gewoon de ".env" uitlezen of andere bestanden

Omdat hij hiervoor eerst het Linux/Windows wachtwoord nodig heeft. Om een HTTP-request te sturen heb je geen wachtwoord nodig, en om een virus in een netwerk te verspreiden evenmin.

Tja, alles kan tevoorschijn komen als de developer incompetent is

De microsoft-werknemers die ASP.NET ontwikkeld zijn nochtans niet zo debiel om wachtwoorden/usernames op de debugpagina te tonen en gaan ervan uit dat de projectontwikkelaar niet te lui is om zijn config-files te openen in een teksteditor.

FTP werkt niet op mijn hosting, ik kan enkel SFTP gebruiken (SSH).

Laravel is een framework voor developers, niet voor mensen die alleen Wordpress installers kunnen hanteren

Kijk om je heen... Er zijn honderdduizenden Laravel websites. Hoeveel van deze websites toont gewoon het SQL-wachtwoord denk je? Zelf als APP_DEBUG=FALSE...

Als er trouwens een nieuwe versie van Laravel in composer terechtkomt die een bug bevat die ervoor zorgt dat de app acts as he's in debug-mode dan lopen onmiddellijk honderdduizenden websites onterecht het risico dat hun wachtwoorden op het internet af te lezen zijn. Schrijf wachtwoorden naar logfiles of dergelijke, deze zijn niet toegankelijk. Ook niet als een werknemer/programmeur in je bedrijf een virus downloadt. Maar toch niet in een HTTP response...

[ Voor 9% gewijzigd door PieterjanDC op 02-01-2019 11:56 ]

[NMe]

PieterjanDC schreef op woensdag 2 januari 2019 @ 11:47:
Als je dit echt wil, en je bent bereid het risico te lopen dat iemand al je wachtwoorden steelt en de accounts gebruikt waar jij voor betaalt, dan kun je steeds gewoon de config-file aanpassen. Security by default vind ik toch belangrijker dan luisteren naar een ontwikkelaar die te lui is om gewoon met één simpele klik zijn .env-file te openen en zijn wachtwoord dat hij dagelijks gebruikt hierin af te lezen. Maar het is natuurlijk hoe je het bekijkt hé.

By default is er geen .env-file. Er is een .env.example-file. Je moet zélf die .env maken en als je dan zo achteloos bent om niet eens te lezen wat je precies in die file zet ligt dat toch echt aan jou. Ja, Laravel kan dingen doen om dit soort achteloosheid beter te faciliteren en dat heeft @Barryvdh dan ook geprobeerd te bereiken. Maar anders dan dat ligt het toch echt aan jou als je een .env.example gaat lopen copy/pasten zonder te weten wat je nou eigenlijk aan het doen bent.

En zelfs als hier niks aan te doen was geweest moet je nog steeds óók Composer verkeerd gebruiken voordat je last hebt van jouw probleem.

PieterjanDC schreef op woensdag 2 januari 2019 @ 11:47:
Als er trouwens een nieuwe versie van Laravel in composer terechtkomt die een bug bevat die ervoor zorgt dat de app acts as he's in debug-mode dan lopen onmiddellijk honderdduizenden websites onterecht het risico dat hun wachtwoorden op het internet af te lezen zijn.

Nee, want een goeie developer heeft geen dev-dependencies geïnstalleerd.

[ Voor 22% gewijzigd door NMe op 02-01-2019 12:05 ]

[PatrickH89]

PieterjanDC schreef op woensdag 2 januari 2019 @ 11:47:

Kijk om je heen... Er zijn honderdduizenden Laravel websites. Hoeveel van deze websites toont gewoon het SQL-wachtwoord denk je? Zelf als APP_DEBUG=FALSE...

Als er trouwens een nieuwe versie van Laravel in composer terechtkomt die een bug bevat die ervoor zorgt dat de app acts as he's in debug-mode dan lopen onmiddellijk honderdduizenden websites onterecht het risico dat hun wachtwoorden op het internet af te lezen zijn. Schrijf wachtwoorden naar logfiles of dergelijke, deze zijn niet toegankelijk. Ook niet als een werknemer/programmeur in je bedrijf een virus downloadt. Maar toch niet in een HTTP response...

Heb je al eens gekeken hoeveel websites gewoon een .env file tonen als je erheen gaat met je browser? PEBCAK. Net als dit probleem. Als er een nieuwe versie van Laravel in composer terechtkomt die een bug bevat die ervoor zorgt dat de app standaard in debug mode staat heb jij natuurlijk netjes whoops niet geïnstalleerd. Bovendien moeten er dan in de Laravel community verscheidene dingen fout zijn gegaan voor dat gebeurt en je moet Laravel zelf dan ook achteloos updaten. Hint: een Laravel installatie update en develop je niet op productie.

Bovendien, in jouw voorbeeld: wat als whoops per ongeluk het filter uitzet in een nieuwe release? Wat als er per ongeluk een SQL vulnerability wordt geïtroduceerd? Wat als gates niet meer correct werken? Zo kunnen we wel bezig blijven. Daarnaast is hier een oplossing voor uitgevonden: tests en CI.

Wat mij betreft verdient deze thread een slotje en moeten we deze onzin verder gewoon negeren. Kijk alsjeblieft eerst naar jezelf, geef toe dat je gewoon niet genoeg kennis hebt om dit (non-)issue aan te kaarten en verbeter said kennis. Door bijvoorbeeld eerst eens wat documentatie te lezen of een Laracasts abonnement te nemen.

[dev10]

PieterjanDC schreef op woensdag 2 januari 2019 @ 11:47:
[...]


Als je met mailgun of sparkpost of Algolia werkt, is de kans groot dat je dezelfde account wilt gebruiken... Indien niet dan is dit OK maar van de 200.000 ontwikkelaars zullen er toch wel 40.000 zijn die dit doen.

Waarom zou je dit willen? In de staging omgeving is dat misschien wel prima, maar voor development zou ik een andere oplossing gebruiken. Laravel biedt een 'Log' maildriver die de mails niet verstuurd maar in een log-bestand zet en anders kun je ook een dienst als Mailtrap gebruiken. Omdat in Laravel de drivers voor het versturen van mail dusdanig geabstraheerd zijn is het geen enkel probleem om dat door middel van je environment variabelen aan te passen.

Daarnaast is je aanname van 20% van de ontwikkelaars nergens op gebaseerd.

PieterjanDC schreef op woensdag 2 januari 2019 @ 11:47:
De microsoft-werknemers die ASP.NET ontwikkeld zijn nochtans niet zo debiel om wachtwoorden/usernames op de debugpagina te tonen en gaan ervan uit dat de projectontwikkelaar niet te lui is om zijn config-files te openen in een teksteditor.

Ik vind het nogal een baud statement om te stellen dat de ontwikkelaars van Laravel debiel zijn omdat er wachtwoorden en usernames getoond worden op een debug pagina. Je kunt op een gegeven moment alles idiot proof maken, maar op een gegeven moment moet je ergens een grens trekken. Als ontwikkelaar van Laravel, mag je er gewoon vanuit gaan dat andere ontwikkelaars gewoon de documentatie lezen.

PatrickH89 schreef op woensdag 2 januari 2019 @ 12:11:
[...]


Heb je al eens gekeken hoeveel websites gewoon een .env file tonen als je erheen gaat met je browser? PEBCAK. Net als dit probleem.

Om hier even op aan te haken: de maker van de PHP dotenv, die gebruikt wordt door Laravel, geeft zelfs expliciet aan dat deze library niet bedoeld is voor een productieomgeving: https://github.com/vlucas...07#issuecomment-273530307

Dit sluit ook weer naadloos aan bij het derde punten in de lijst met 12 factoren: https://12factor.net/config

[PatrickH89]

dev10 schreef op woensdag 2 januari 2019 @ 12:32:

[...]


Om hier even op aan te haken: de maker van de PHP dotenv, die gebruikt wordt door Laravel, geeft zelfs expliciet aan dat deze library niet bedoeld is voor een productieomgeving: https://github.com/vlucas...07#issuecomment-273530307

Dit sluit ook weer naadloos aan bij het derde punten in de lijst met 12 factoren: https://12factor.net/config

Helemaal correct. Op productie stel je de environment variabelen in bij de webserver, niet met een .env file. Dit is normaal gesproken trouwens uitsluitend een performance issue, want alleen de public folder in Laravel is ervoor bedoeld om benaderbaar te zijn in de web root. Je kunt dit bij Laravel echter ook doen door wel een .env file te hebben en de config simpelweg te cachen (zodat said file nooit wordt ingeladen buiten het command om de config daadwerkelijk te cachen).

Dus het 'probleem' in deze thread wordt hiermee niet opgelost.

[ Voor 11% gewijzigd door PatrickH89 op 02-01-2019 12:42 ]

[Chloortablet]

[...]


Om hier even op aan te haken: de maker van de PHP dotenv, die gebruikt wordt door Laravel, geeft zelfs expliciet aan dat deze library niet bedoeld is voor een productieomgeving: https://github.com/vlucas...07#issuecomment-273530307

Dit sluit ook weer naadloos aan bij het derde punten in de lijst met 12 factoren: https://12factor.net/config

Wat dus ook de reden is dat je voor deployment altijd nog eens

code:

php artisan optimize

draait, waardoor het .ENV bestand niet meer wordt geladen, maar de config uit de cache komt

Mocht je dan ten onrechte toch nog ergens buiten je config een .env variabele op willen vragen, dan komt daar gewoon NULL uit.

[ Voor 10% gewijzigd door Chloortablet op 02-01-2019 12:43 ]

[NMe]

dev10 schreef op woensdag 2 januari 2019 @ 12:32:
Om hier even op aan te haken: de maker van de PHP dotenv, die gebruikt wordt door Laravel, geeft zelfs expliciet aan dat deze library niet bedoeld is voor een productieomgeving: https://github.com/vlucas...07#issuecomment-273530307

De enige echte reden daarvoor is performance, en de performancehit is dermate klein dat ik me daar niet al te druk over zou maken. Op een shared host waarop niet elke site in zijn eigen Docker-container draait kun je bijvoorbeeld ook niet heel anders.

[xh3adshotx]

PieterjanDC schreef op woensdag 2 januari 2019 @ 11:47:
Als je met mailgun of sparkpost of Algolia werkt, is de kans groot dat je dezelfde account wilt gebruiken... Indien niet dan is dit OK maar van de 200.000 ontwikkelaars zullen er toch wel 40.000 zijn die dit doen.

Geen idee wie het een goed idee lijkt om dezelfde accounts voor productie en development te gebruiken maar mag hopen dat het minder dan 40000 professionele ontwikkelaars zijn. Nog steeds is 40000 minder dan 200000 dus laten we het bij de best practices houden en geen rare dingen gaan doen omdat een minderheid dat lekker makkelijk vind.

Daarnaast zijn, zoals genoemd, andere methode beschikbaar om deze functionaliteit te testen. Meestal worden die dan ook gebruikt en word maar incidenteel getest met de dienst zelf.

PieterjanDC schreef op woensdag 2 januari 2019 @ 11:47:
Als je dit echt wil, en je bent bereid het risico te lopen dat iemand al je wachtwoorden steelt en de accounts gebruikt waar jij voor betaalt, dan kun je steeds gewoon de config-file aanpassen. Security by default vind ik toch belangrijker dan luisteren naar een ontwikkelaar die te lui is om gewoon met één simpele klik zijn .env-file te openen en zijn wachtwoord dat hij dagelijks gebruikt hierin af te lezen. Maar het is natuurlijk hoe je het bekijkt hé.

Enig idee wat het verschil is tussen een developer en productie omgeving? Als het goed is kan niemand anders behalve jij bij de developer omgeving. In principe is er ook security by default: er is geen enkele voorbeeld environment voor productie meegeleverd. Daar moet je als developer dus zelf over nadenken en die kan jij precies instellen zoals je wilt. Doe je dat niet en staat app_debug nog aan? Geen probleem want je hebt de dev dependencies niet. Tenzij je natuurlijk selectief bent met je security by default en die uit gemakt wél op productie installeerd.

PieterjanDC schreef op woensdag 2 januari 2019 @ 11:47:
Nee, echt? Ik ken zelfs geen websites waarop je je profiel kan aanpassen waarop staat "Dit is je wachtwoord, wil je dit wachtwoord wijzigen?". Technisch is dit uiteraard zelf niet mogelijk (read bcrypt), maar er is dus zelfs geen website in de wereld die het in zijn hoofd haalt om een gebruiker zijn wachtwoord in een HTTP-response te printen. Laat staan een SQL-wachtwoord.
En je vertrouwt enkel en alleen op je firewall dat deze alles gaat tegenhouden? Wat met je eigen computer? Gaat een virus die slechts 20 ms nodig heeft om een webrequest naar een testserver in je netwerk te sturen ook tegengehouden worden? Of misschien de computer van je zus?

Nogmaals, zoek even het verschil tussen een developer en productie omgeving op. Op een developer omgeving kan je in principe alle data laten tonen die je nodig vind - inclusief wachtwoorden en secrets aangezien niemand erbij kan als je het goed inricht. Als dat het development proces versneld is dat zeker acceptabel. In productie stuur je natuurlijk (bijna) nooit een wachtwoord/secret tenzij dat nadrukkelijk nodig is voor een requirement. In het laatste geval gebruik je minimaal HTTPS ipv HTTP.

En het hele idee van een firewall is om dingen af te schermen op je computer. Als ik een virus op mijn computer heb maak ik mij meer zorgen om de source code en bijbehorende configuratiefiles etc. dan om een HTTP request naar een exception pagina met wachtwoorden/secrets erin. Als mijn zus een virus op haar computer heeft kan die nergens bij: de firewall houd verkeer van buiten tegen en de webserver is alleen op localhost gebound (dus zelfs zonder firewall kan je geen verbinding maken).

PieterjanDC schreef op woensdag 2 januari 2019 @ 11:47:
Omdat hij hiervoor eerst het Linux/Windows wachtwoord nodig heeft. Om een HTTP-request te sturen heb je geen wachtwoord nodig, en om een virus in een netwerk te verspreiden evenmin.

Ja, mooi, maar als jij zonder wachtwoord een virus op m'n netwerk kan verspreiden ga je toch gelijk voor de webserver en jat je alle bestanden i.p.v. een of andere gare request naar een exceptie pagina? Voor de rest: firewall? Bounden aan localhost i.p.v. je IP?

PieterjanDC schreef op woensdag 2 januari 2019 @ 11:47:
De microsoft-werknemers die ASP.NET ontwikkeld zijn nochtans niet zo debiel om wachtwoorden/usernames op de debugpagina te tonen en gaan ervan uit dat de projectontwikkelaar niet te lui is om zijn config-files te openen in een teksteditor.

FTP werkt niet op mijn hosting, ik kan enkel SFTP gebruiken (SSH).

Sorry maar hier heb je het weer mis. Ook een exception pagina van ASP.net (Core) kan gevoelige informatie bevatten. Dat staat zelfs in een mooi oranje vak in de documentatie: Dus ja, volgens jou zijn die developers ook "debiel" - maar ik begin te twijfelen wie daadwerkelijk "debiel" is.

quote: https://docs.microsoft.co...dling?view=aspnetcore-2.2

Warning

Enable the Developer Exception Page only when the app is running in the Development environment. You don't want to share detailed exception information publicly when the app runs in production. Learn more about configuring environments.

PieterjanDC schreef op woensdag 2 januari 2019 @ 11:47:
Kijk om je heen... Er zijn honderdduizenden Laravel websites. Hoeveel van deze websites toont gewoon het SQL-wachtwoord denk je? Zelf als APP_DEBUG=FALSE...

Alle websites waarvan de developer te incompetent is om de documentatie te lezen/volgen en de developer dependencies installeerd op een productie omgeving.

PieterjanDC schreef op woensdag 2 januari 2019 @ 11:47:
Als er trouwens een nieuwe versie van Laravel in composer terechtkomt die een bug bevat die ervoor zorgt dat de app acts as he's in debug-mode dan lopen onmiddellijk honderdduizenden websites onterecht het risico dat hun wachtwoorden op het internet af te lezen zijn. Schrijf wachtwoorden naar logfiles of dergelijke, deze zijn niet toegankelijk. Ook niet als een werknemer/programmeur in je bedrijf een virus downloadt. Maar toch niet in een HTTP response...

Nee hoor, want je hebt de developer dependencies niet dus dat gebeurt niet.

[Radiant]

PieterjanDC schreef op woensdag 2 januari 2019 @ 11:47:
[...]

Kijk om je heen... Er zijn honderdduizenden Laravel websites. Hoeveel van deze websites toont gewoon het SQL-wachtwoord denk je? Zelf als APP_DEBUG=FALSE...

Als er trouwens een nieuwe versie van Laravel in composer terechtkomt die een bug bevat die ervoor zorgt dat de app acts as he's in debug-mode dan lopen onmiddellijk honderdduizenden websites onterecht het risico dat hun wachtwoorden op het internet af te lezen zijn. Schrijf wachtwoorden naar logfiles of dergelijke, deze zijn niet toegankelijk. Ook niet als een werknemer/programmeur in je bedrijf een virus downloadt. Maar toch niet in een HTTP response...

Lukraak dependencies updaten zonder te reviewen/testen is ook al zo'n slecht idee. Een bug die ervoor zorgt dat je app in debug mode draait lijkt me onwaarschijnlijk; andere bugs waardoor je hele productiesite omvalt des te meer. Laatst nog gezien met een JS-library die van een CDN kwam die ineens even gewijzigd werd; plop, productiesite kapot..

Of je website heeft ineens een backdoor..
Of steelt credentials van je users
Of je hele site valt even om..

Grappig dat je zelf zoveel best practices in het ontwikkelproces negeert, maar wel zit te hameren op een ini-mini kans op het lekken van een credential waar een hacker als het goed is helemaal niets aan heeft, behalve als je meerdere dingen fout doet.

[PieterjanDC]

Ik weet dat ik fouten gemaakt heb, daar hoef je me heus niet op te wijzen hoor.
Ik doe wat de handleiding zegt, maar als de handleiding op niets trekt heb je hier ook niet veel aan.

Ik heb namelijk alles juist geconfigureerd nu, maar zit nog altijd vast aan een slecht framework waar op ieder ogenblik terug fuck-ups kunnen in terechtkomen door developers die het normaal vinden dat credentials gewoon op een webpagina terechtkomen.

But not to worry, dat laatste ben ik ook aan het aanpakken. Gewoon door een professioneel framework (ASP.NET Core) te gebruiken

[ Voor 88% gewijzigd door PieterjanDC op 28-04-2019 14:18 ]

[mcDavid]

Ja, altijd een goed plan, gelijk naar een ander framework in een compleet andere taal grijpen. Kun je alle fouten weer opnieuw maken