Beveiliging → Compleet kwaadwillige POST analyse - beste manier van werken

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Top Low-Code Developer Gezocht!

Bedrijfsomschrijving Unieke Kansen, Uitstekende Arbeidsvoorwaarden & Inspirerend Team Wij zijn een toonaangevende, internationale organisatie die de toekomst van technologie vormgeeft door het creëren van innovatieve en baanbrekende oplossingen. Ons succes is gebaseerd op een hecht en gepassioneerd team van professionals die altijd streven naar het overtreffen van verwachtingen. Als jij deel wilt uitmaken van een dynamische, vooruitstrevende en inspirerende werkomgeving, dan is dit de perfecte kans voor jou! Functieomschrijving Als Low-Code Developer ben je een cruciaal onderdeel van ons team. Je werkt samen met collega's uit verschillende disciplines om geavanceerde applicaties te ontwikkelen en te optimaliseren met behulp van Low-code

Bekijk vacature »

Bart Smulders

Bart Smulders

18/04/2021 15:00:05
Quote Anchor link
Voor het onderwerp beveiliging ben ik op zoek naar de beste manier om een foutieve post in de database op te slaan om daarna een analyse uit te voeren.

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?
 
PHP hulp

PHP hulp

28/03/2024 23:02:46
 
Ad Fundum

Ad Fundum

18/04/2021 15:47:18
Quote Anchor link
Ik neem gemakshalve aan dat je $_POST bedoelt zonder $_FILES, maar je kunt de gehele $_POST gewoon in de database opslaan als TEXT. Want zo komt het ook binnen via CGI. PHP maakt er een array van, je kunt daarvan gebruik maken of je kunt het weer weer plat maken.
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.
Gewijzigd op 18/04/2021 15:52:23 door Ad Fundum
 
Ward van der Put
Moderator

Ward van der Put

18/04/2021 16:40:24
Quote Anchor link
Webservers bieden de mogelijkheid om alle input en/of output te loggen, bijvoorbeeld met mod_dumpio bij Apache.

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.
 
Ad Fundum

Ad Fundum

18/04/2021 18:57:22
Quote Anchor link
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.
 
Bart Smulders

Bart Smulders

18/04/2021 19:09:09
Quote Anchor link
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 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.
 
Ad Fundum

Ad Fundum

19/04/2021 08:01:26
Quote Anchor link
Dat lijkt me wel vreemd, heb je een website alleen voor kwaadwillenden?

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.
Gewijzigd op 19/04/2021 08:09:37 door Ad Fundum
 
Thom nvt

Thom nvt

19/04/2021 08:44:09
Quote Anchor link
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.
 
Bart Smulders

Bart Smulders

19/04/2021 21:06:58
Quote Anchor link
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.


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.
 
Ward van der Put
Moderator

Ward van der Put

19/04/2021 21:28:44
Quote Anchor link
Misschien eens een OWASP cheatsheet erop naslaan:

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?
 
Ozzie PHP

Ozzie PHP

20/04/2021 00:32:50
Quote Anchor link
Iedere server en website wordt met enige regelmaat belaagd door kwaadwillenden. Vaak gebeurt dit geheel automatisch door bots. Zo kan het gebeuren dat jouw server/website op 1 dag wel 10.000 keer wordt aangevallen door bots die jouw server/website testen op zwakheden. Het proberen te POSTen van formulieren kan daar een onderdeel van zijn.

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).
 
Thom nvt

Thom nvt

20/04/2021 07:08:05
Quote Anchor link
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.


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.


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.
 
Ad Fundum

Ad Fundum

20/04/2021 09:38:14
Quote Anchor link
Het is heel goed om na te denken over beveiliging en AVG. De reacties zijn adviezen die je een hoop moeite kunnen besparen, en die er voor zorgen dat je een betere graad van beveiliging en privacy krijgt.

> "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.
Gewijzigd op 20/04/2021 09:40:48 door Ad Fundum
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.