Post request illegaal?

[Ferra]

Ik weet niet of dit onder software ontwikkeling hoort, maar ik heb de volgende 2 vragen:

Ik maak binnen mijn website gebruik van json bestanden die ik meestuur in een post request. Dit gebeurt uiteraard onder water, maar je kunt het achterhalen door via de dev tools van Chrome bijv. dieper op de code in te zoomen.

Een vriend van me zei hierop dat je dit nu heel makkelijk kunt nabouwen en de response json hiermee kunt afvangen. Vraag is of dit mag en of dit niet in strijd is met de wet. Ik kan me namelijk voorstellen dat je er niet op zit te wachten dat iemand dmv een loopje even door alle zoekresultaten loopt. Weten jullie dit?

Daarnaast ben ik benieuwd hoe ik dit kan monitoren? Zijn dit dan heel veel requests vanaf bijv. ip-adres A?

[RobIII]

En met welke wet zou dat in strijd zijn dan? Het hangt er nogal vanaf wat je doet met welke intenties, maar ga er van uit dat wat een gewone bezoeker kan "zien" een "hacker" ook kan zien. Of dat nou een POST is of whatever en of dat dan "netjes" via de site gebeurt of via een script/"bot". Als je doel is het overnemen van de volledige productcatalogus van je concurrent dan, nee, dat is zeer waarschijnlijk op een aantal punten illegaal. Als het doel het aanleggen van een index voor een zoekmachine is dan wordt het al een ander verhaal. Either way, een "POST" is niks bijzonders; dat is puur een technisch iets en is verder irrelevant in het verhaal.

Ik weet ook niet wat je verwacht op te lossen met monitoren, maar je kunt zaken "rate limiten" bijvoorbeeld door meer dan X aantal requests per seconde/uur/dag/jaar/whatever (per IP/gebruiker/account/...) te weigeren door met een code 429 te antwoorden (of, hell, eke andere vorm van weigeren van zinnige response).

[ Voor 26% gewijzigd door RobIII op 07-12-2020 09:27 ]

[Pin0]

Als je json post en de response opvraagt zonder enige vorm van authenticatie kan iedereen dat doen op het moment dat het ergens online staat. De urls zijn inderdaad gewoon te zien met chrome devtools etc.

Of het kwaad kan hangt af van wat de functionaliteiten zijn. Het indienen van een zoekvraag en het teruggeven van resultaten kan niet echt kwaad.
Erger wordt het wanneer er bij het posten data wordt weggeschreven in een database ed. Of dat er persoonsgegevens meekomen met de json response.

Je zal iedere request dus moeten authentiseren. Dat kan bijvoorbeeld met Json webtokens, maar er zijn meer methoden.

Of het mag van de wet kan je over discussiëren, maar dat ontslaat je niet van het inbouwen van authenticatie.

[Kalentum]

Beschouw je website als een publieke API en behandel het ook zo.

Je kan in de websitegebruiksvoorwaarden op laten nemen dat je niet met scriptjes ofzo tegen je site aan mag praten. Daarmee voorkom je het natuurlijk niet maar heb je wel een stok om mee te slaan.

Wat betreft illegaal: er is geen wet die afdwingt dat je met een webbrowser naar sites moet gaan. Als ik een klein scriptje schrijf om tegen jouw website te praten is dat niet verboden (voor zover ik weet)

Verder hangt het er enorm af van de schade die iemand kan aanbrengen door jou POST requests te misbruiken. Is het alleen maar irritant (hogere load, meer traffic) of kan er daadwerkelijk schade aan worden gericht? Of kan ik financieel gewin halen uit het geautomatiseerd tegen je site aan praten?

Maar in de kern is het heel simpel: als iets met een browser mogelijk is, is het ook mogelijk met een scriptje en kan iedereen de communicatie tussen je site en de browser uitlezen.

[Barryvdh]

Er is wel zoiets als het Databankenrecht;
Wikipedia: Databankenrecht
https://www.rvo.nl/onderw...eschermen/databankenrecht

Maar dat zal van de case afliggen of het van toepassing is.

[Mr. HTTP]

Ik maak binnen mijn website gebruik van json bestanden die ik meestuur in een post request. Dit gebeurt uiteraard onder water, maar je kunt het achterhalen door via de dev tools van Chrome bijv. dieper op de code in te zoomen.
Een vriend van me zei hierop dat je dit nu heel makkelijk kunt nabouwen en de response json hiermee kunt afvangen.

En wat maakt dat nabouwen volgens die vriend dan zo makkelijk? Kan die POST request bijv. stiekem veel meer dan via de normale interface mogelijk is? Zoals beheersfunctionaliteit of het wijzigen/opvragen van gegevens zonder dat zekerheid bestaat dat zo'n actie wordt uitgevoerd door de juiste gebruiker/in de juiste context? Als dat zo is dan heeft zorgen maken om nabouwen totaal geen prio, dan moet de focus gelegt worden op betere beveiliging.

Vraag is of dit mag en of dit niet in strijd is met de wet. Ik kan me namelijk voorstellen dat je er niet op zit te wachten dat iemand dmv een loopje even door alle zoekresultaten loopt. Weten jullie dit?

De wet biedt je wel wat bescherming maar de beste bescherming zou simpel gezegd in de code van je website moeten zitten (en opbouw van je systeem). Als ik bijv. een website zou willen scrapen dan mag ik dat niet doen op een manier waarbij ik die web site onnodig belast. Dan breng ik namelijk schade toe. Ik mag ook niet een hele web site scrapen en vervolgens met een ander jasje weer online brengen (denk aan auteursrecht). Maar er zijn ook genoeg situaties waarin er helemaal niets fouts gebeurt bij het scrapen; denk aan scrapen voor onderzoek, AI training of online diensten zoals zoekmachines. Zoekmachines hebben in hun database kopieen van webpaginas met daaraan gekoppelde meta data waarbij de gebruikers van de zoekmachine nooit een hele kopie krijgen van de zoekmachine als resultaat maar een kleine preview-snippit en de link naar de bron (een juridisch correcte bronvermelding dus). Daarnaast moet je beseffen dat dit niet een zaak is voor de politie. Als iemand echt te kwader trouw aan het scrapen is, zul je deze nog moeten herleiden tot een persoon of organisatie en zelf voor het gerecht moeten slepen (en ook alleen als je serieus denkt te gaan winnen/schikken).

Samenvattend kun je er dus vanuit gaan dat iemand dat loopje vroeg of laat gaat uitvoeren (zeker als je interessante data hebt) en je effort/focus moet zich dan niet richten op wetgeving en rechtzaken (tenzij je teveel tijd en geld hebt) maar op preventie.

Daarnaast ben ik benieuwd hoe ik dit kan monitoren? Zijn dit dan heel veel requests vanaf bijv. ip-adres A?

Er zijn tal van methoden om je te beschermen tegen ongewenst gedrag op jouw website. Een aantal verschillende voorbeelden;
- hoe je code is geschreven
- server configuratie
- cloud protection
- real-time traffic analysis service met anomaly detection

Hoe je code is geschreven
Stel je hebt een pagina met een overzicht van producten voor een bepaalde productcategorie. Op de pagina staat dat er 1337 producten in de categorie voorkomen. In de eindgebruikers interface kun je bladeren met maximaal 50 producten per pagina. Maar na inspectie van de URL blijkt dat die 50 producten voortkomen uit de query optie 'rpp' (results per page) en als ik die aanpas naar 1337 krijg ik in een klap alle gegevens terug. De oplossing is simpel; zorg dat de onderliggende code de query optie 'rpp' juist valideert en limiteert en dus nooit meer dan 50 producten teruggeeft. Je kunt je daarnaast ook afvragen waarom de optie 'rpp' uberhaupt aanspreekbaar moet zijn via de URL. Hoe meer functionaliteit (dan strikt noodzakelijk), des te meer er mis kan gaan of misbruikt kan worden...

Server configuratie
Voor nginx heb je bijvoorbeeld deze modules:

ngx_http_limit_req_module
limits the request processing rate per key, for example, the processing rate of requests coming from a single IP address.

ngx_http_limit_conn_module
limits the number of connections per key, for example, the number of connections from a single IP address.

Cloud beveiliging
Hiermee gaat een bezoekje aan jouw web site eerst via het netwerk van de cloud provider die functioneert als proxy/tussenpersoon voor jouw echte web site. Omdat elke request via het network van de cloud provider loopt wordt onveilig of onbetrouwbaar verkeer geidentificeert en gefiltert. Denk hierbij aan DDoS beveiliging of het tonen van een captcha als je 100 keer op F5 hebt gedrukt binnen 1 minuut. Maar het kan ook bekende SPAM IPs op voorhand blokkeren of andere twijfelachtige netwerken.

Real-time traffic analysis met anomaly detection
Anomaly Detection in Network Traffic using Multivariate State Machines

[armageddon_2k1]

CORS op je server goed instellen dat het alleen van jouw eigen frontend mag komen?

[qless]

In principe mag je niks vertrouwen wat via browser binnenkomt. Alle invoer moet gecontrolleerd worden voordat je er iets mee doet, zoals escaping e.d. om sql injection te voorkomen etc.

[RobIII]

armageddon_2k1 schreef op vrijdag 11 december 2020 @ 08:26:
CORS op je server goed instellen dat het alleen van jouw eigen frontend mag komen?

CORS doet buiten een browser helemaal niks. Het weerhoudt er niemand van een POST te doen met cURL of een script of...

[Hydra]

RobIII schreef op vrijdag 11 december 2020 @ 09:07:
CORS doet buiten een browser helemaal niks. Het weerhoudt er niemand van een POST te doen met cURL of een script of...

Precies. Een proxy ertussen die de headers filtert (en aanpast indien nodig) en je bent klaar.

[armageddon_2k1]

Ja, dat klopt :-)

[labee]

Ik kwam nog twee leuke presentaties tegen over de beveiliging van WebAPI's

YouTube: Common API Security Pitfalls - Philippe De Ryck
YouTube: How to Build an Effective API Security Strategy