Hoe je JavaScript-agents, CSP en crawlers omzeilt (client-side beveiligingstesten)

TL;DR:

• Client-side scripts die worden gebruikt voor beveiligingscontroles kunnen onwerkzaam worden gemaakt met standaard browserfunctionaliteit zoals XHR-overrides.
• Hoewel dit voorkomen kan worden, hebben we geen leverancier kunnen vinden die een preventiemethode heeft geïmplementeerd, waardoor beveiligingsoplossingen kwetsbaar zijn voor omzeilingen.
• Crawler/Scanner/Agent-loze oplossingen hebben door hun ontwerp beperkt zicht. Hierdoor kan een kwaadwillende de scans detecteren en de beveiligingsscanner honingpotten door onschadelijke code te serveren, terwijl kwaadaardige code naar eindgebruikers wordt gestuurd.
• Het doel van deze blogpost is om bewustzijn te creëren over het risico van client-side aanvallen en de exploits die kwaadwillenden gebruiken om beveiligingsoplossingen krachteloos te maken. We bieden ook oplossingen om deze omzeilingsmethoden te voorkomen.

In deze blog:

• Waarom je je compliance-tools moet testen
• Hoe je JavaScript-agents omzeilt
• Hoe je CSP omzeilt
• Hoe je crawlers omzeilt
• Defensietips + veiligere alternatieven
• Disclaimers & verantwoorde openbaarmaking

Doel & reikwijdte. Dit artikel is uitsluitend gepubliceerd voor educatieve en defensieve doeleinden. De voorbeelden zijn bedoeld om algemeen browsergedrag en ontwerpbeperkingen toe te lichten die van invloed kunnen zijn op client-side beveiligingstools; het is geen stap-voor-stap aanvalshandleiding en is niet gericht op een specifieke leverancier, product of organisatie. We keuren onrechtmatig gebruik van de hier besproken technieken niet goed. Als je een kwetsbaarheid ontdekt die verband houdt met de inhoud van dit bericht, volg dan de richtlijnen voor verantwoorde openbaarmaking — zie het gedeelte "Verantwoorde openbaarmaking" aan het einde van dit bericht. Alle tests zijn uitgevoerd in overeenstemming met de toepasselijke servicevoorwaarden van de leverancier en de geldende wetgeving.

"In een wereld waar compliance-tools falen bij basale omzeilingstechnieken, is niemand veiliger en vergroten valse veiligheidsgevoelens de problemen."

- Simon Wijckmans, CEO, cside

Waarom je je client-side / compliance-tools moet testen

We hebben lang getwijfeld of we dit artikel moesten schrijven. Enerzijds willen we geen leveranciers aanvallen. Anderzijds lopen we allemaal risico als beveiligingsoplossingen worden verkocht die eenvoudig te omzeilen zijn. We zijn cside begonnen om een veiliger internet te bouwen, met als doel beveiligingsangst online te verminderen.

Soms betekent dat het aanwijzen van zwakke plekken in beveiligingsperimeters, vooral wanneer die voortkomen uit bekende platformbeperkingen.

Hoewel we begrijpen dat compliance voor veel bedrijven neerkomt op een tool die simpelweg een vakje aanvinkt, zien wij compliance als een kans om de beveiliging van een platform te verbeteren. Zeker wanneer deze compliancevereisten zijn opgesteld om aanvallen te voorkomen.

Stel je een geavanceerde rookmelder voor die een brand perfect detecteert, maar waarvan de alarmkabel is doorgeknipt voordat het alarm kan klinken. De detectie is perfect, maar de respons vindt nooit plaats. Dit is de gevaarlijke realiteit voor sommige client-side beveiligingsoplossingen die binnen een webbrowser werken.

Wanneer een browser een pagina laadt, worden scripts uitgevoerd in dezelfde JavaScript-omgeving en kunnen ze interageren met gedeelde globale objecten. Onder bepaalde omstandigheden kan dit ertoe leiden dat één script een ander kan observeren of aanpassen. Zelfs geavanceerde client-side detecties kunnen beperkt worden als hun uitgaande rapportage wordt verstoord. Dit is een praktisch risico dat verdedigers in overweging moeten nemen wanneer ze uitsluitend vertrouwen op client-side telemetrie. Een kwaadaardig script kan de uitgaande rapportage van een beveiligingstool verstoren, wat in sommige gevallen het zicht op een lopend incident aanzienlijk kan verminderen.

Om die reden heeft cside besloten niet volledig te vertrouwen op client-side detecties, maar in plaats daarvan te kiezen voor een geavanceerdere en genuanceerdere aanpak.

Hoe je een JavaScript-agent omzeilt

De primaire manier waarop een browser communiceert met een server is via netwerkverzoeken, doorgaans via de fetch API of XMLHttpRequest (XHR). Voor een ontwikkelaar lijken dit misschien fundamentele, onveranderlijke onderdelen van de browser. In werkelijkheid zijn het gewoon eigenschappen van het globale window object die elk script opnieuw kan definiëren.

Veel legitieme scripts werken met de fetch API — dit is een gangbare en algemeen bekende aanpak.

Een script kan deze API's echter ook gebruiken om uitgaande aanroepen van client-side beveiligingsleveranciers te onderscheppen. Dit gaat eenvoudig door:

• Herdefiniëren van window.fetch om uitgaande beveiligingsrapporten te inspecteren of te blokkeren.
• Aanpassen van XMLHttpRequest.prototype.send om meldingen te onderscheppen en te verwijderen.
• Omhullen van deze functies om verzoekpayloads te wijzigen, beveiligingsheaders te verwijderen of gevoelige gegevens te loggen.

Laten we zien hoe eenvoudig dit is. Stel dat je site twee scripts laadt:

1. Een gecompromitteerde chat-plugin van een derde partij.
2. Een beveiligingstool.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>My Application</title>
  <script src="https://false-sense-of-security.com/security.js"></script>

  <script src="https://compromised-chat-plugin.com/plugin.js"></script>
</head>
<body>
  </body>
</html>

Hieronder staat de code die de gecompromitteerde plugin.js zou kunnen bevatten. Zoals veel scripts doen voor legitieme doeleinden, werkt het met de XMLHttpRequest browser-API. Hieronder staat algemeen softwaregedrag.

// NIET UITVOERBAAR: conceptuele aanvallersstroom (uitsluitend illustratief)
// Dit blok vermijdt bewust uitvoerbare JS. Het legt de stappen op hoog niveau uit
// die een aanvaller zou kunnen nemen om client-side telemetrie te verstoren.
// Plak dit NIET in een JS-runtime met de verwachting dat het werkt — het is puur beschrijvend.
/
  Conceptuele stappen die een aanvaller zou kunnen gebruiken (hoog niveau):
    1) DETECT_TELEMETRY_SENDER(stack): gebruik heuristieken / runtime-markers om te raden
       welk script telemetrie probeert te verzenden.
    2) INTERCEPT_OUTBOUND_CALL(request): het verzoek kort sluiten, aanpassen of verwijderen.
    3) LOG_DECISION(info): optioneel vastleggen dat een telemetrieaanroep is onderdrukt.
/
/* ---------- Conceptuele bewerkingen (GEEN echte functies) ---------- */
DETECT_TELEMETRY_SENDER(stack)
// geeft terug: SENDER_MATCHED | NO_MATCH
// OPMERKING: "stack" is een conceptuele weergave van de runtime-context
INTERCEPT_OUTBOUND_CALL(request)
// mogelijke uitkomsten (conceptueel): DROP | MODIFY(request) | FORWARD(request)
LOG_DECISION(info)
// beslissing vastleggen voor analyse (conceptueel)
/* ---------- Gesimuleerd scenario (alleen tekst) ---------- */
// Gesimuleerde runtime: de aanvaller inspecteert de huidige aanroepstack (conceptueel)
SIMULATED_STACK = "...security.js at ..."
// Conceptuele detectiestap
DETECT_RESULT => DETECT_TELEMETRY_SENDER(SIMULATED_STACK)  // => SENDER_MATCHED
// Conceptuele onderscheppingsbeslissing
INTERCEPT_OUTCOME => INTERCEPT_OUTBOUND_CALL({ to: "/telemetry" })  // => DROP
// Gesimuleerd logboek
LOG_DECISION("Telemetrierapport onderdrukt (conceptueel)")
/* ---------- Gesimuleerde console-uitvoer (voor begrip van de lezer) ---------- */
// >> DETECT_TELEMETRY_SENDER(...) => SENDER_MATCHED
// >> INTERCEPT_OUTBOUND_CALL(...) => DROP
// >> LOG: "Telemetrierapport onderdrukt (conceptueel)"

Met dit algemene codegedrag actief is je beveiligingstool effectief geblokkeerd. Het kan kwaadaardig gedrag nog steeds detecteren, maar de noodoproepen (fetch- of XHR-verzoeken) worden onderschept en in een zwart gat gegooid. Je zult nooit weten dat er een aanval heeft plaatsgevonden.

Hoe dit voorkomen kan worden

Dit probleem voorkomen voor fetch-verzoeken is heel eenvoudig: sla gewoon een lokale kopie op, je hoeft niets eens te hernoemen.

// Sla `fetch` lokaal op voor later gebruik:
const { fetch } = window;

// Gebruik later in de code een lokale versie van fetch:
fetch(...)

XHR vergt iets meer werk, maar is nog steeds mogelijk met een paar regels code.

// Sla prototypes lokaal op voor later gebruik:
const { apply } = Reflect;
const { open, send } = XMLHttpRequest.prototype;
const { XMLHttpRequest } = window;

// In een asynchroon deel van de code:
const request = new XMLHttpRequest();
apply(open, request, ["POST", "/endpoint"]);
apply(send, request, []);

Onze analyse van gangbare detectiemethoden suggereert dat deze oplossingen vatbaar kunnen zijn voor de hierboven beschreven omzeilingsconcepten.

We raden elke beveiligingsleverancier sterk aan om deze aanpakken te onderzoeken om klanten beter te beschermen.

Elk beveiligingsscript moet als eerste worden uitgevoerd. Als dat niet het geval is, kan een kwaadwillende de API's kapen die het beveiligingsscript probeert te beschermen. Dit is een essentiële vereiste.

Hoe je een 'agent-loze' oplossing omzeilt

Veel leveranciers bieden een 'agent-loze' aanpak. Dit is in feite een scanner of crawler die wordt gehost op een cloudplatform. Zoals bij elke applicatie moeten netwerkverzoeken ergens vandaan komen. En voor de meeste van deze oplossingen komen ze van een IP-adres dat eigendom is van cloudproviders.

Wanneer een netwerkverzoek wordt gedaan, wordt een verzoekheader meegestuurd met een aantal waardevolle gegevenspunten.

Host, User-Agent, Accept-Language, Referer (opzettelijk verkeerd gespeld) en nog veel meer.

De infrastructuur van een client-side opgehaald script ziet deze waarden en besluit welke scriptversie te serveren. Dit is logisch en bestaat om goede redenen. Een marketingtool kan verschillende versies van zijn script serveren op basis van de browser waarmee het verzoek wordt gedaan, of op basis van de locatie van de gebruiker om privacynaleving te vereenvoudigen. Maar ook advertenties zijn willekeurig, ze veranderen voortdurend en zijn client-side JavaScripts. Client-side scripts zijn dynamische functies en veel oplossingen hebben die dynamische mogelijkheden nodig.

Dit is echter een kans voor een kwaadwillende. Ter illustratie:

// Illustratieve pseudo-logica; niet bedoeld voor productie of misbruik.
const CLOUD_ASNS = new Set([
// Veelgebruikte ASN's van cloudproviders. Voeg meer toe indien nodig
16509, // AMAZON-02
14618, // AMAZON-AES
24940, // HETZNER
212317, // HETZNER
398657, // MICROSOFT AZURE DEDICATED
]);
export default {
async fetch(request) {
// server voegt netwerkinformatie toe aan het verzoek
const asn = request.xyz?.asn;
<span class="kw">const</span> body = CLOUD_ASNS
  ? <span class="str">`console.log("we're good");\n`</span>
  : <span class="str">`console.log("we're bad");\n`</span>;

<span class="kw">return new</span> Response(body, {
  headers: {
    <span class="str">"content-type"</span>: <span class="str">"application/javascript; charset=utf-8"</span>,
    <span class="str">"cache-control"</span>: <span class="str">"no-store"</span>,
  },
});

},
};

Het bovenstaande voorbeeld kan op elk type webserver worden ingezet, inclusief eenvoudige PaaS-platforms die geen verificatie vereisen.

Wat het bovenstaande script doet is vrij eenvoudig. Wanneer een verzoek afkomstig is van een cloudprovider, wordt een schoon script geserveerd. Elk ander verzoek krijgt een kwaadaardig script.

Natuurlijk kan de kwaadwillende meer logica toevoegen. Zoals: serveer het kwaadaardige script alleen als de ontwikkelaarstools gesloten zijn en slechts 5% van de tijd. Dit maakt handmatige detectie moeilijker.

Dit kan het zicht van een crawler-gebaseerde oplossing op gerichte aanvallen aanzienlijk beperken.

Het gebruik van een residentiële proxy om eruit te zien als een gewone residentiële gebruiker zal waarschijnlijk weinig verschil maken. Een kwaadwillende kan het gebruik van een residentiële proxy nog steeds detecteren.

Het IPv4-netwerk telt 4,3 miljard IP-adressen, IPv6 340 undeciljoen (ja, dat is een woord), browser-user-agents veranderen voortdurend... er zijn oneindige niveaus van entropie en een kwaadwillende kan een aanval altijd nog steeds samplen. Uiteindelijk is geen enkele kunstmatige methode om iets menselijk te laten lijken, echt menselijk. Gemotiveerde kwaadwillenden zullen manieren vinden om een echte menselijke gebruiker te onderscheiden van een geautomatiseerde workflow. Marketingpagina's van leveranciers kunnen je anders doen geloven, maar technische feiten zijn technische feiten.

Een andere eenvoudige methode is het maken van een client-side subverzoek op basis van beschikbare browserparameters. Dit maakt het mogelijk om de volledige reikwijdte van browser-API's te gebruiken om te beslissen of een subverzoek al dan niet wordt gedaan.

Veel crawler-gebaseerde oplossingen controleren de bron-URL simpelweg aan de hand van een lijst van bekende kwaadaardige domeinnamen afkomstig van threat feed-providers. Het probleem met deze aanpak is dat een gerichte aanval niet wordt gemarkeerd en dat het lang kan duren voordat een aanval wordt opgemerkt. Kwaadwillenden kunnen detectie van kwaadaardige domeinen ook eenvoudig omzeilen door veelgebruikte domeinnamen zoals googletagmanager.com te gebruiken om kwaadaardige scripts te hosten.

Een crawler-gebaseerde oplossing benadert een dynamische beveiligingsdreiging met een statische beveiligingsmentaliteit. Hoewel dit handig is, werkt het door ontwerp niet. Om dit punt verder te illustreren, laten we een aantal veelgebruikte aanvalsmethoden doornemen en hoe ze detectie omzeilen.

Geofenced aanvallen

Wat het zijn: Geofenced aanvallen serveren een kwaadaardig script alleen aan gebruikers op specifieke locaties of IP-ranges (bijvoorbeeld bepaalde mobiele provider-ranges in het VK of de EU) en serveren een onschadelijk script aan iedereen anders.

Waarom scanners ze missen:

• Scanners, crawlers en 'agent-loze' tools draaien bijna altijd vanuit cloud provider-IP's of bekende proxy-ranges.
• Aanvallers kunnen eenvoudig een lijst van cloud-ASN's bijhouden en vermijden kwaadaardige payloads te sturen naar die IP's.
• Als gevolg hiervan ziet de scanner herhaaldelijk het 'schone' script en observeert nooit de echte aanval.

Waarom cside ze detecteert:

• cside observeert scripts terwijl ze worden uitgevoerd in de browsers van echte gebruikers, op echte residentiële en mobiele netwerken.
• Als een script kwaadaardig gedrag vertoont voor een echte gebruiker, kan cside het gedrag detecteren, en in gatekeepermode zelfs de payload blokkeren voordat deze wordt uitgevoerd.

Met andere woorden: Reflectiz ziet wat aanvallers hun scanners laten zien; cside ziet wat aanvallers daadwerkelijk naar jouw gebruikers sturen.

User-Agent gerichte aanvallen

Dit zijn aanvallen waarbij een kwaadaardige payload alleen wordt geïnjecteerd op bepaalde browsers, bijvoorbeeld selenium, Safari, Chromium of een specifiek besturingssysteem.

De meeste scanners, crawlers en in dit geval 'agent-loze' oplossingen komen voort uit een reeks voorspelbare User-Agent-strings. Ze emuleren zelden mobiele apparaatheaders.

En in de zeldzame gevallen dat een scanner zijn User-Agents wijzigt, sluit de agent gewoonlijk niet aan bij de werkelijke verzoekpayloads. Scanners draaien doorgaans op Linux-gebaseerde besturingssystemen, wat betekent dat een kwaadwillende op basis van het TCP-verzoekpakket kan zien welk besturingssysteem daadwerkelijk wordt gebruikt. Dit resulteert erin dat de kwaadaardige payload niet naar de scanner wordt gestuurd, omdat Linux zelden door een echte menselijke gebruiker wordt gebruikt.

Tijdgebonden aanvallen

Dit zijn aanvallen die alleen worden uitgevoerd op specifieke tijdstippen van de dag. Bijvoorbeeld: buiten kantooruren wanneer de beveiligingsteams niet aanwezig zijn. Scanners draaien periodiek, waardoor een tijdgebonden aanpak er eenvoudig toe kan leiden dat het onschadelijke script wordt gescand, maar niet het kwaadaardige script.

Gecamoufleerde of voorwaardelijke code-uitvoering

Dit zijn aanvallen die gebruikersacties benutten om een kwaadaardig script te injecteren. De volledige reikwijdte van browser-API's kan hiervoor worden gebruikt, bijvoorbeeld het controleren op muisbewegingen, het vereisen van een bepaald ritme in toetsenbordinvoer, het verifiëren van het bestaan van cookies, timinganalyse (gebruikt om headless browsers te detecteren)...

Gewoonlijk wordt deze methode gebruikt om de kwaadaardige payload slechts eenmaal te serveren, zodat een beveiligingsonderzoeker de kwaadaardige payload niet opnieuw kan vinden. Dit is bijzonder uitdagend omdat ontwikkelaarstools in browsers vaak geen eerdere staten opslaan van vóór het openen van de ontwikkelaarstools. Waardoor een vernieuwing noodzakelijk is.

Een scanner zal nooit in staat zijn om echt gebruikersgedrag op dezelfde manier na te bootsen als een echte gebruiker.

Per-sessie dynamische payloads

Dit zijn aanvallen waarbij de kwaadwillende automatisch unieke kwaadaardige payloads genereert voor elke echte gebruiker, met behulp van technieken zoals het omhullen van scripts met dynamische sleutels, polymorfische JavaScript, A/B-testachtige logica... Vaak worden de authenticatie-indicatoren van de gebruiker als voorwaarde gebruikt om de kwaadaardige payloads te injecteren.

Intermitterende supply-chain vergiftiging

Dit is een uiterst veelgebruikte methode bij Magecart-stijl aanvallen. Een kwaadwillende kan de aanval simpelweg samplen om de kwaadaardige scriptinhoud slechts aan 1% van de gebruikers te serveren. Deze methode maakt het een stuk moeilijker voor een bezoeker om de aanval op te merken, omdat de volledig willekeurige injectie van het script het reproduceren van de aanval een stuk moeilijker maakt.

Conclusie

Op basis van publiek gedocumenteerde fundamentele browsermogelijkheden en standaard JavaScript-functionaliteit kunnen crawler-gebaseerde benaderingen te maken krijgen met de hierboven beschreven beperkingen.

We moedigen leveranciers aan om dergelijke beperkingen duidelijk te documenteren en hun mogelijkheden niet te overdrijven. Klanten moeten beschikken over de informatie die nodig is om weloverwogen implementatiebeslissingen te nemen in het belang van de veiligheid van het web.

Hoe je CSP omzeilt

Een andere veelgebruikte beveiligingsaanpak is content security policies.

CSP kan nuttig zijn bij het beperken van de blootstelling door de reikwijdte van toegestane bronnen te verkleinen. Maar veel websites gebruiken tools die voor de hele wereld open staan om scripts naar te uploaden. Als een beleid niet strikt genoeg is, leidt dit tot een eenvoudige omzeiling. Maar zelfs als een beleid strikt genoeg is, kan een aanvaller ervoor kiezen de aanval uit te voeren op een manier die CSP niet monitort.

Hoe dit werkt: zodra een kwaadwillende toegang krijgt tot een webapplicatie, kunnen ze een subverzoek injecteren naar een Google Tag Manager-container. Voorbeeld:

<script async src="https://www.googletagmanager[.]com/gtm.js?id=GTM-XXXXXX"></script>

Binnen deze container kunnen ze elk gewenst script opnemen. Inclusief inline scripts die nog moeilijker te beveiligen zijn.

Omdat CSP geen echte context heeft van de scriptpayload, is het zicht vrij beperkt.

Sommige oplossingen proberen dit te veranderen door achteraf een fetch naar het script te doen.

Maar hetzelfde probleem als bij de crawler doet zich voor: alles wat niet-menselijk lijkt, zal waarschijnlijk een andere respons ontvangen dan een menselijke gebruiker zou krijgen.

Hoewel je de tag manager-container in de CSP kunt specificeren, is dit niet erg gebruikelijk. Er zijn ook andere domeinen zoals "githubusercontent[.]com" die met hetzelfde probleem te maken hebben.

En uiteindelijk, als een bron gecompromitteerd is door een incident bij de leverancier of doordat de domeinnaam verloopt, zal CSP niet kunnen helpen.

In tegenstelling tot de client-side scriptmethode hebben we geen betrouwbare techniek binnen CSP kunnen vinden die het gebruik van een vertrouwd domein als omzeilingsmethode zou vermijden. De domeineigenaren zelf zouden preventieve maatregelen kunnen nemen, maar hebben dit tot op heden niet gedaan. CSP heeft beperkingen, maar zoals bij elk beveiligingsprogramma is gelaagdheid een goede praktijk. CSP wordt gebruikt voor meer dan waarvoor het oorspronkelijk was ontworpen.

Bedrijven die CSP adopteren, hebben vaak moeite om het te onderhouden en krijgen regelmatig te maken met uitval van client-side tools wanneer beleidsregels wijzigingen blokkeren.

cside is actief betrokken bij webstandaardenorganisaties om de specificatie van CSP en andere methoden zoals SRI te verbeteren.

Veiligere alternatieven (de cside-aanpak)

Het cside-team heeft uitgebreide ervaring in client-side beveiliging. Gedurende onze ervaringen hebben we vastgesteld dat kwaadwillenden opereren op een niveau van verfijning dat de overhand heeft op sommige beveiligingsbenaderingen. Als de beloning hoog genoeg is, is elke leemte in een beveiligingsdetectiemodel een kans voor een kwaadwillende.

Gezien de specificatiebeperkingen van browsers voor client-side beveiliging moesten we creatief zijn, en daarom hebben we client-side beveiliging anders benaderd dan elke andere oplossing op de markt.

• Direct Mode - Eenvoudigst: We controleren scriptgedrag in de browser en halen de scripts op aan onze kant. Vervolgens verifiëren we of we hetzelfde script hebben ontvangen. We plaatsen onszelf niet in het pad van een script tenzij je ons daar expliciet om vraagt. Voeg gewoon één script toe aan de site, het duurt seconden.
• Gatekeeper Mode - Veiligst: We controleren scriptgedrag en cside plaatst zichzelf in het midden tussen de ongecontroleerde derde partij en de eindgebruiker — alleen voor scripts die je nog niet vertrouwde. Voeg gewoon één script toe aan de site, het duurt seconden.
• Scan mode - Snelst: Als je geen script aan de site kunt toevoegen, scant cside het. We gebruiken de cside-dreigingsinformatie verzameld door duizenden andere websites met gecombineerd miljarden bezoekers om je site zo goed mogelijk te beveiligen.

De combinatie van het bovenstaande brengt ons het dichtst bij volledige dekking die technisch vandaag de dag mogelijk is.

Als prettige bijkomstigheid hebben we met sommige van de aanpakken die we hebben genomen websites sneller kunnen maken, afhankelijk van de scripts op de webpagina. Een oplossing in het midden plaatsen maakt dingen alleen langzamer als ze al volledig geoptimaliseerd zijn, wat vaak niet het geval is.

Hiermee helpt cside bedrijven compliance te bereiken, of het nu gericht is op beveiliging of privacy.

cside draagt actief bij aan de W3C in de hoop aandacht te creëren voor client-side beveiliging. Met als doel aanpassingen aan de browserspecificatie te realiseren om volledig kogelvrije client-side beveiliging mogelijk te maken.

Bij cside registreren we aanvallen. Als je deze blogpost leest, ben je waarschijnlijk een voldoende hoogwaardig doelwit voor een kwaadwillende om enige mentale capaciteit te investeren in het inspecteren van hoe jouw webbeveiliging werkt. Het is beter om veilig te zijn en ervan uit te gaan dat een kwaadwillende zal proberen de beveiligingsoplossingen die je gebruikt te omzeilen. Gebruik dus oplossingen die een stap vooruit denken.

Disclaimer & juridische veilige haven

Dit bericht is uitsluitend bedoeld voor informatieve en educatieve doeleinden. Het vormt geen juridisch advies, en de standpunten en technische analyses die worden uitgedrukt zijn van onszelf. Niets hier mag worden opgevat als een erkenning van aansprakelijkheid door enige partij.

Geen van de bovengenoemde benaderingen of codevoorbeelden is geavanceerd of uitsluitend bedoeld voor kwaadaardige doeleinden. Dit zijn basale JavaScript-gebruiksscenario's, op geen enkele manier is dit eigendomsrechtelijk beschermd. De gedeelde fragmenten worden actief gebruikt in client-side scripts voor legitieme doeleinden. Wij zijn niet verantwoordelijk voor enig gebruik van deze basale JavaScript-functies door een kwaadwillende partij.

Alle voorbeeldcode en pseudo-code zijn uitsluitend illustratief. Ze zijn opzettelijk generiek, niet-eigendomsrechtelijk beschermd en niet ontworpen om in echte omgevingen te draaien. Hun doel is het benadrukken van defensieve overwegingen, niet het voorzien van aanvallers van werkende exploits.

Let op: het proberen toe te passen van deze technieken op systemen die je niet bezit, of zonder expliciete toestemming, kan wetten schenden zoals de Amerikaanse Computer Fraud and Abuse Act, de Britse Computer Misuse Act, of vergelijkbare regelgeving in andere rechtsgebieden.

We ondersteunen actief beveiligingsonderzoek te goeder trouw. Als je het hieronder beschreven proces voor verantwoorde openbaarmaking volgt, zullen we je onderzoek als geautoriseerd behandelen en geen juridische stappen tegen je ondernemen. Kortom, deze inhoud is bedoeld om verdedigers te helpen beschermingen te versterken, niet om kwaadaardig gedrag mogelijk te maken.

Verantwoorde openbaarmaking

Als je denkt een kwetsbaarheid te hebben ontdekt die verband houdt met de inhoud van dit bericht (inclusief scripts van derden of integraties waarnaar we verwijzen), publiceer dan geen exploitdetails openbaar. Stuur in plaats daarvan een e-mail naar

hello@cside.com met als onderwerp "Vulnerability report [korte titel]".

Voeg reproduceerbare stappen, getroffen URL's en een veilige contactmethode toe. We bevestigen ontvangst binnen 5 werkdagen en coördineren de oplossing. We zullen geen juridische stappen ondernemen tegen te goeder trouw handelende melders die deze richtlijnen volgen.