Beveiliging → Compleet kwaadwillige POST analyse - beste manier van werken
Eerst dacht ik aan base64_encode om de complete post op te vangen.
Dit leek me niet meer voldoende wanneer er geen limiet op de ingevoerde gegevens staat en de server te lang zou bezig zijn met verwerken (download) van de post met alle gevolgen van dien.
tenzij de base64 code in een fysiek bestand op de server kan bewaard worden onder bv foutecode01012021.1.txt
Foutafhandeling is niet eenvoudig en denken als een hacker helpt niet bij het veiligheidsgevoel.
Hoe kan dit het beste worden aangepakt?
Een webserver heeft altijd een limiet staan op de grootte een HTTP post, en er zijn wat meer variabelen die daar invloed op hebben, dus dat is geen probleem.
Daarnaast moet je nadenken over wat je gaat opslaan voor beveiliging. Een CSRF-token is niet heel relevant. Sommige dingen mag je niet zomaar opslaan, denk aan gebruikersinformatie zoals persoonsgegevens of medische informatie.
Een aardig beginpunt is deze Cheat Sheet van OWASP:
https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
Ook een aanrader is hun Zed Attack Proxy of ZAP, waarmee je zelf je eigen website of webapplicatie kunt PEN-testen. Zie: https://owasp.org/www-project-zap/
Voor het denken als een hacker zijn verschillende boeken geschreven, op bijvoorbeeld bol.com kan je de nodige vinden.
Ik zou alleen het wiel opnieuw uitvinden als je voor de analyse van dergelijke log files ook een veel betere oplossing hebt en die niet voldoende heeft aan de standaard logging.
De betere oplossing is toch echt om het zelf vast te leggen. Dan weet je in ieder geval wat je vastlegt, en kan je nagedacht hebben over wat je daar allemaal mee moet, wie dat gaat doen en hoe, en wanneer de gegevens weer verwijderd dienen te worden.
Ad Fundum op 18/04/2021 18:57:22:
Dat lijkt me niet echt zaligmakend, alle uitvoer is gewoon veel te veel. Daar komt bij dat je onvermijdelijk dingen gaat loggen waar geen wettelijke grondslag voor is, dus juridisch niet in de haak. En dat alles wordt vastgelegd in het error log maakt het weinig praktisch, de echte errors raken daarmee zoek.
De betere oplossing is toch echt om het zelf vast te leggen. Dan weet je in ieder geval wat je vastlegt, en kan je nagedacht hebben over wat je daar allemaal mee moet, wie dat gaat doen en hoe, en wanneer de gegevens weer verwijderd dienen te worden.
De betere oplossing is toch echt om het zelf vast te leggen. Dan weet je in ieder geval wat je vastlegt, en kan je nagedacht hebben over wat je daar allemaal mee moet, wie dat gaat doen en hoe, en wanneer de gegevens weer verwijderd dienen te worden.
De bedoeling van de volledige post opslaan is enkel wanneer een kwaadwillende gebruiker dingen doet met een formulier waarvoor het formulier niet bestemd is.
Gezien de kwaadwillende gebruiker er ook niets mee inzit om een formulier te manipuleren zie ik er het kwaad niet van in. Volgens GDPR dient men op de hoogte te zijn van wat men verwerkt.Zo zal dan staan dat een gebruiker die andere intenties heeft dan origineel bedoeld, volledig zijn akkoord geeft om verwerkt te worden.
De logs hebben dan ook een maximale houdbaarheid.
Zo nee, hoe weet je dan van te voren wie kwaadwillend is en wie niet?
Als er mensen bij zitten zonder kwaad in de zin, hoe weet je dan van te voren het verschil of sla je van hen ook alles op?
Mocht je ondanks alles toch echt alles op moeten slaan, en je wilt voor onderzoek of debugging echt alles in beeld krijgen, dan ben je mijns inziens veel beter af door het complete netwerkverkeer te loggen. Daar zijn weer andere tools voor, zo kan je de netwerkkaart in promiscuous mode zetten om het verkeer te dupliceren en op een andere machine te loggen. Inspecteren kan dan met Wireshark. Ga je nog een stap verder dan neem je er een SIEM oplossing voor. Dat alles scheelt voor een productie-omgeving die dan niet extra wordt belast met logging. Je moet ook beheer van identiteiten en toegangsbeheer goed ingeregeld hebben, anders houden logbestanden geen stand in een rechtzaak mocht je op juridisch vlak iets tegen de eenmaal gevonden kwaadwillenden willen beginnen.
Met andere woorden, als de website en het budget klein genoeg zijn, kan je alles loggen op je productieserver. Maar je hebt dan slechts één stap gezet ten koste van privacy en performance, terwijl je volgens mij veiligheid veel breder zou moeten zien.
Als een kwaadwillende een formulier probeert te manipuleren zal je dat op moeten vangen met validatie en input filtering, niet met logging.
Het loggen van foutieve invoer zou kunnen, maar wie zegt dat het dan direct een kwaadwillende is?
Beter nog, wat is "kwaadwillende invoer"? Hoe filter je daar op? Hoe houd je ontwikkelingen in security/hacking bij? Wat wil je uiteindelijk met de gelogde data doen?
Het word een nogal ingewikkelde en dus kostbare aangelegenheid om dat allemaal bij te werken.
Daarnaast is opsporing behoorlijk kansloos op het moment dat er VPNs of Tor gebruikt worden.
Robots (bots) zou je nog wel kunnen afvangen maar daar bestaan prima oplossingen voor zoals Fail2Ban.
Het nut van het loggen van al die requests + data ontgaat mij dan ook, als je de server-side code goed inricht is dat behoorlijk zinloos.
Een SIEM zoals Ad Fundum beschrijft zou de ideale tool zijn om verdacht gedrag op te sporen maar dat is inderdaad niet interessant voor kleine websites en budgetten.
Thom nvt op 19/04/2021 08:44:09:
Volgens mij beschrijf je een probleem wat niet opgelost moet worden met logging.
Als een kwaadwillende een formulier probeert te manipuleren zal je dat op moeten vangen met validatie en input filtering, niet met logging.
Het loggen van foutieve invoer zou kunnen, maar wie zegt dat het dan direct een kwaadwillende is?
Beter nog, wat is "kwaadwillende invoer"? Hoe filter je daar op? Hoe houd je ontwikkelingen in security/hacking bij? Wat wil je uiteindelijk met de gelogde data doen?
Het word een nogal ingewikkelde en dus kostbare aangelegenheid om dat allemaal bij te werken.
Daarnaast is opsporing behoorlijk kansloos op het moment dat er VPNs of Tor gebruikt worden.
Robots (bots) zou je nog wel kunnen afvangen maar daar bestaan prima oplossingen voor zoals Fail2Ban.
Het nut van het loggen van al die requests + data ontgaat mij dan ook, als je de server-side code goed inricht is dat behoorlijk zinloos.
Een SIEM zoals Ad Fundum beschrijft zou de ideale tool zijn om verdacht gedrag op te sporen maar dat is inderdaad niet interessant voor kleine websites en budgetten.
Als een kwaadwillende een formulier probeert te manipuleren zal je dat op moeten vangen met validatie en input filtering, niet met logging.
Het loggen van foutieve invoer zou kunnen, maar wie zegt dat het dan direct een kwaadwillende is?
Beter nog, wat is "kwaadwillende invoer"? Hoe filter je daar op? Hoe houd je ontwikkelingen in security/hacking bij? Wat wil je uiteindelijk met de gelogde data doen?
Het word een nogal ingewikkelde en dus kostbare aangelegenheid om dat allemaal bij te werken.
Daarnaast is opsporing behoorlijk kansloos op het moment dat er VPNs of Tor gebruikt worden.
Robots (bots) zou je nog wel kunnen afvangen maar daar bestaan prima oplossingen voor zoals Fail2Ban.
Het nut van het loggen van al die requests + data ontgaat mij dan ook, als je de server-side code goed inricht is dat behoorlijk zinloos.
Een SIEM zoals Ad Fundum beschrijft zou de ideale tool zijn om verdacht gedrag op te sporen maar dat is inderdaad niet interessant voor kleine websites en budgetten.
Voor alle duidelijkheid?
Het betreft een webapp.
Mede omdat veiligheid en verantwoordelijkheid over de vergaarde informatie niet in vreemde handen zou komen en opdat GDPR dient nageleefd te worden primeert het doel de middelen.
Hoe weet je of iemand een formulier kwaadwillend invult?
Wanneer het formulier rechtstreeks werd aangeroepen vanuit een host buiten het eigen domein.
Wanneer velden zoals checkboxen andere zaken bevatten dan "on" en niet leeg zijn.
Er zijn denk ik genoeg parameters die aangeven of een manipulatie al dan niet kwaadwillend was.
Zoals eerder aangehaald neem ik dit mee op in de privacy verklaring.
Het algeheel loggen van alle $_POST zal niet gebeuren.
Enkel wanneer foutieve informatie werd doorgegeven.
Hoe gaat u na een hack anders nagaan waar het fout ging?
Reeds bedankt voor jullie input.
https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
Als je alleen onveilige posts gaat loggen, heb je kennelijk al een mechanisme werkend dat feilloos een onderscheid kan maken tussen veilige en onveilige requests. Dat lijkt me om te beginnen al een illusie omdat je zo de spreekwoordelijke wolf in schaapskleren mist.
Je hebt dan bovendien een compleet beleid nodig voor alle kritieke data. Mag iemand volgens jouw policy bijvoorbeeld zijn naam wijzigen? Of is dat iemand die probeert de boel op te lichten door zijn ware identiteit te verhullen door zijn eigennaam te vervangen door een valse identiteit?
Als ik je goed begrijp wil je al die aanvallen gaan loggen? En dan? Ga je iedere dag die 10.000 IP-addressen natrekken? IP-addressen aan de andere kant van de wereld? Aanvallen via anonieme proxy lists? Dat is onbegonnen werk.
Ik denk dat je iets wilt bereiken, maar de verkeerde aanpak kiest.
Je geeft aan dat je illegale acties wilt loggen. Blijkbaar weet jij dus op voorhand welke acties illegaal zijn.
De betere aanpak is dan om die illegale acties uit te sluiten. Als iemand dus een bepaalde illegale handeling uitvoert, dan BLOKKEER je die handeling. Je laat de handeling dus niet doorgaan en gaat die vervolgens loggen, maar je zorgt ervoor dat die handeling simpelweg niet kan plaatsvinden.
Wat jij nu doet is de voordeur barricaderen en het zijraampje open laten staan. Zodra er dan iemand door het zijraampje naar binnen klimt, begin jij te loggen. Beter is om ervoor te zorgen dat het zijraampje op slot is, en nog beter is om ervoor te zorgen dat er helemaal geen zijraampje is.
Hopelijk snap je wat ik / wij bedoel(en).
Bart Smulders op 19/04/2021 21:06:58:
Hoe weet je of iemand een formulier kwaadwillend invult?
Wanneer het formulier rechtstreeks werd aangeroepen vanuit een host buiten het eigen domein.
Wanneer velden zoals checkboxen andere zaken bevatten dan "on" en niet leeg zijn.
Er zijn denk ik genoeg parameters die aangeven of een manipulatie al dan niet kwaadwillend was.
Wanneer het formulier rechtstreeks werd aangeroepen vanuit een host buiten het eigen domein.
Wanneer velden zoals checkboxen andere zaken bevatten dan "on" en niet leeg zijn.
Er zijn denk ik genoeg parameters die aangeven of een manipulatie al dan niet kwaadwillend was.
Dat zijn allemaal zaken die je in je validatie moet opvangen en daar moet blokkeren.
Het loggen van die "kwaadwillende" requests is vrij zinloos, het loggen dat zoiets gebeurd is is al zinvoller (zie ook de reactie van Ozzie en mijn toelichting hieronder).
De enige uitzondering is het rechtstreeks aanroepen van een host buiten het eigen domein (dat lijkt mij voor een webapp ondoenlijk). Hoe kan ik als gebruiker dan ooit dat formulier invullen? Ik zit namelijk ook niet in jouw domein.
Wat wel zou kunnnen is om CORS te gaan gebruiken in je webserver en applicatie, daarmee dwing je op HTTP niveau al e.e.a. af. CSRF tokens zijn ook een goede toevoeging voor formulieren met gevoelige data die maar 1x mogen worden verzonden.
Bart Smulders op 19/04/2021 21:06:58:
Het algeheel loggen van alle $_POST zal niet gebeuren.
Enkel wanneer foutieve informatie werd doorgegeven.
Enkel wanneer foutieve informatie werd doorgegeven.
Zoals Ozzie al aangaf, dat kunnen er al snel duizenden tot honderdduizenden per dag zijn.
Wat ga je met al die data doen? En waar ga je het laten?
Ter indicatie: sommige applicaties die ik (zakelijk) beheer genereren 50 tot 100 gigabyte aan auditlogs per dag.
Totaal onbegonnen werk om door te spitten zonder goede en automatische/AI filtering.
Bart Smulders op 19/04/2021 21:06:58:
Hoe gaat u na een hack anders nagaan waar het fout ging?
Dit komt misschien wat hard over maar als je werkelijk denkt dat hackers via een webformuliertje (mits goed gevalideerd/gefiltert) binnen proberen te komen ben je óf enorm naïef óf je hebt een aardig kennisgat om te vullen.
Goede beveiliging gaat áltijd voor goede logging. Ja, je moet beide doen maar het loggen van alle data van foutieve/kwaadwillende acties is verre van de eerste stap en in de meeste gevallen zinloos.
Zet eerst je voordeur dicht voordat je gaat bijhouden wie er allemaal binnenkomt.
> "Wanneer het formulier rechtstreeks werd aangeroepen vanuit een host buiten het eigen domein."
Dit type aanval kan worden tegengegaan met een CSRF-token, alle informatie over hoe je dat doet staat hier:
https://owasp.org/www-community/attacks/csrf
> "Wanneer velden zoals checkboxen andere zaken bevatten dan "on" en niet leeg zijn."
Een webapplicatie moet nooit klakkeloos alles opslaan, maar elk ingestuurd formulier controleren of het voldoet aan de eigen ("business"-) logica. Voldoet een ingestuurd formulier niet, dan moet de webapplicatie het formulier weigeren, en - voor de 99% niet-kwaadwillenden - vriendelijk aangeven wat ze moeten doen om het wel goed te krijgen.
Als je deze opties die hier worden aangereikt afzet tegen de redelijke zinloosheid van alles maar opslaan, dan lijkt het mij evident dat je niet voor alles opslaan kiest.
Alles opslaan kost nog veel meer moeite dan je zou willen: volgens de GDPR hoort mensen ervan op de hoogte te stellen, met de mogelijkheid van keuzes maken, gegevens inzien, corrigeren, exporteren etc. Daarnaast mag je niet alle gegevens opslaan, zoals persoonsgegevens en zeker geen medische gegevens. Hiervoor moet nog veel meer worden geregeld, opslag en toegang tot logging moet aan eisen voldoen. Zie bijvoorbeeld NEN-ISO/IEC 27000:2017+A11:2020.
Het doet pijn wanneer je webapplicatie gehackt wordt, maar alles loggen is als een camera op je auto richten en achteraf naar de politie gaan met beelden van inbraak waar ze niets mee kunnen, de inbreker had een bivakmuts op en eigenlijk had je al nooit de camera op de openbare weg mogen richten.
Je kunt dan beter voorkomen dat het nog eens fout gaat, vanwege alle redenen die al zijn gegeven.