Reflectiz vs cside

TL;DR: cside vs Reflectiz:

• Reflectiz is een scanner-gebaseerde, agent-less oplossing. Het crawlt periodiek je site vanaf cloud-IP's.
• cside combineert real-time in-browser scriptgedragmonitoring en een optionele 'gatekeeper'-engine om te zorgen voor volledige zichtbaarheid op het gedrag dat de gebruiker ziet.
• Client-side scriptaanvallen zijn vaak dynamisch en sterk voorwaardelijk (geo, User-Agent, tijdgebonden, willekeurig, expliciet cloud IP-adressen vermijdend).
• cside kan kwaadaardige acties door scripts in real-time detecteren en voorkomen. Volledige scriptcontext wordt bewaard voor forensics maar slaat geen door gebruikers ingevoerde data of PII op.
• Kortom: cside ziet en beschermt echte gebruikers in real-time. Waar Reflectiz snapshots maakt voor een compliance-checkbox. Reflectiz ziet wat aanvallers hen laten zien; cside ziet wat aanvallers daadwerkelijk naar je gebruikers sturen.
• Onafhankelijk onderzoek door ISACA, beveiligingsonderzoekers bij Google en Oracle maar ook academisch onderzoek door Bournemouth University concludeert consequent dat scanner-gebaseerde client-side beveiliging geen gelijke tred kan houden met moderne, dynamische browser-side bedreigingen.

Waarom we deze vergelijking schreven

Dit artikel legt uit hoe Reflectiz en cside client-side beveiliging anders benaderen en waarom dat verschil er in de praktijk toe doet.

We zijn duidelijk bevooroordeeld - je bent op de cside-website - maar de vergelijking is gebaseerd op:

• Openbaar beschikbare technische informatie
• Gedocumenteerde branche-aanvallen (zoals Polyfill en Magecart-stijl campagnes)
• PCI DSS 4.0.1-richtlijnen
• Onze eigen en onze klanten hun real-world ervaringen

We hebben Reflectiz uitgenodigd om deze pagina te beoordelen en eventuele feitelijke correcties te delen. Op het moment van schrijven hebben ze geen wijzigingen aangeleverd.

Reflectiz vergelijken met cside

Samengevat:

• cside biedt real-time detectie, blokkering, script-payload logging, dynamische gedragsanalyse en een QSA-gevalideerd PCI-dashboard.
• Reflectiz vertrouwt primair op periodieke scans, die gerichte, voorwaardelijke aanvallen die alleen aan echte gebruikers worden geleverd niet kunnen zien.
• cside kan veel soorten client-side aanvallen voorkomen of detecteren die elke scanner-architectuur, inclusief Reflectiz, per definitie niet zal zien.

Gebruikersrecensies: Reflectiz vs cside

Hier is hoe echte gebruikers cside en Reflectiz hebben beoordeeld op basis van hun ervaring met detectienauwkeurigheid, ondersteuningskwaliteit en algemene betrouwbaarheid.

Je kunt de gebruikersrecensies voor cside bekijken op Sourceforge of G2.

"Ik ben blij dat we hun product hebben gevonden en het heeft ons geholpen bij het behalen van PCI-compliancedoelen die voorheen een beetje overweldigend leken. cside's product was precies wat we zochten voor een fractie van de prijs die andere concurrenten boden." - Anonieme Review, Sourceforge (Citaat uit Sourceforge Review van cside)

Onafhankelijke QSA-validatie: Reflectiz vs cside

Onafhankelijke QSA-validatie is een belangrijke indicator of de beveiligingsclaims van een leverancier technisch zijn geverifieerd. Hier is hoe Reflectiz en cside vergelijken op externe beoordelingen.

cside:

• Beoordeeld en goedgekeurd door VikingCloud, een van de grootste Qualified Security Assessor (QSA) bedrijven.
• Onderhoudt SAQ-D-certificering
• Erkend door compliance-consultants en gebruikt door QSA-partners tijdens PCI-gereedheidsbeoordelingen.

Reflectiz:

• Geen openbaar beschikbare QSA-goedkeuring of certificering vermeld op hun site of documentatie.
• Vertrouwt op zelf-geattesteerde claims in plaats van validatie door derden.

Wat is Reflectiz?

Reflectiz is een scanner-gebaseerde, agent-less tool die zich richt op compliance en privacy voor client-side dependencies op websites. In plaats van code in je gebruikersbrowsers te draaien, crawlt het je site vanaf externe infrastructuur, analyseert welke scripts worden geladen en rapporteert problemen die het vindt.

Hoe Reflectiz werkt (Scanner-architectuur)

Reflectiz gebruikt wat het een "eigen browser" noemt om geselecteerde pagina's en pagina's ontdekt via de sitemap te crawlen. In de praktijk betekent dit:

• Verzoeken komen vanaf cloud- of datacenter IP-bereiken, niet van echte gebruikers.
• Pagina's worden periodiek gecontroleerd, niet continu en niet real-time.
• Het ziet de scripts die op dat moment aan zijn crawler worden geserveerd, niet noodzakelijkerwijs wat echte gebruikers in de loop van de tijd zien.

Dit agent-less, scanner-only ontwerp heeft enkele voordelen (geen codewijzigingen vereist) maar is niet eenvoudiger te implementeren omdat captcha's en botdetectie moeten worden omzeild of de scanner moet worden toegestaan. Maar ook inloggegevens en sessietokens moeten worden gebruikt. Dit creëert ook een eenvoudig platform voor het detecteren van de scanner dat een kwaadwillende kan gebruiken om de kwaadaardige actie niet uit te voeren wanneer de beveiligingsscan wordt uitgevoerd. Het concept van een website-scanner voor dynamische aanvallen introduceert een inherente blinde vlek wanneer scripts zich anders gedragen voor verschillende gebruikers, locaties, apparaten of tijden. Wat precies is hoe veel moderne client-side aanvallen werken.

Hoewel scanners eenvoudig te bouwen en goedkoop te bedienen zijn, kunnen ze worden gebruikt voor statische beveiligingsbehoeften, maar er is een fundamenteel ontwerpprobleem met deze benadering in de context van dynamische scripts.

Dit maakt het onwaarschijnlijk dat kwaadaardig gedrag door kwaadwillende actoren wordt gedetecteerd.

Een client-side asset is zeer dynamisch. Het serveert doelbewust specifieke content aan specifieke apparaten, locaties, tijden van de dag enz. Met een combinatie van HTTP-headers en andere externe signalen of het willekeurig maken van responses.

Kwaadwillenden gebruiken dit in hun voordeel. De meeste gerichte client-side aanvallen worden gesampled of alleen uitgevoerd onder specifieke omstandigheden, en zeker niet tegen een cloud IP-adres…

Er zijn talloze voorbeelden hiervan: de Polyfill-aanval leidde alleen gebruikers om op specifieke mobiele apparaten in bepaalde Europese landen, oudere Magecart-stijl aanvallen vertoonden een vergelijkbaar patroon.

Een crawler kan proberen gebruikersactiviteit na te bootsen, maar het is per definitie geen gebruikersactiviteit. Dus krijgt het niet de exacte payload van wat alle gebruikers ontvangen. Er zijn veel aanwijzingen die achterblijven die aangeven dat een scanner een scanner is en geen mens, zelfs doelbewust gebouwde residential proxies zijn gemakkelijk te detecteren. Kwaadwillenden die grote logo-leveranciers targeten, zullen de moeite investeren om scanners te vermijden en goedaardige content aan die scanners te serveren. We hebben in detail uitgelegd hoe bypasses worden ontworpen in onze blogpost, How to Bypass JavaScript Agents, CSP, and Crawlers.

Een leverancier die alleen een crawler aanbiedt, zou deze intelligence van een andere bron moeten kopen.

cside biedt een crawler voor gevallen waarin een klant geen wijzigingen aan hun code kan aanbrengen, maar het grote verschil is dat we de threat intelligence gebruiken die we zien van alle andere websites die onze on-site diensten gebruiken. Hoewel deze benadering nog steeds geen aanval zal elimineren, is het zeker veel capabeler in het detecteren van aanvallen dan het kopen van threat intel op de open markt.

Hoe cside werkt (Real-User Monitoring + Gatekeeper + Scanner)

cside's client-side dependency beveiligingsoplossingen zijn gebouwd op een eenvoudig principe: om gebruikers te beschermen, moet je precies zien wat hun browsers zien. Anders dan scanner-only tools die een site crawlen vanaf cloud-IP's, analyseert cside scriptgedrag in echte gebruikerssessies en verifieert script-integriteit in real-time en kan optioneel onze eigen 'gatekeeper'-infrastructuur gebruiken. Omdat de meeste moderne aanvallen voorwaardelijk of gericht zijn, is deze echte-gebruiker zichtbaarheid essentieel.

Ons team heeft decennia besteed aan het werken in browserbeveiliging en draagt actief bij aan standaardenorganisaties zoals de W3C, en helpt de toekomst van client-side beveiliging vorm te geven. Deze achtergrond informeerde cside's architectuur: een systeem dat real-user gedragsmonitoring, een optionele gatekeeper-laag en een intelligence-gedreven scanner combineert. Samen bieden deze benaderingen de meest complete technische dekking die mogelijk is voor dynamische scriptbedreigingen.

Waarom een meerlaagse benadering noodzakelijk is

Browsers waren niet ontworpen met client-side beveiliging in gedachten. Browsers' native functionaliteit zoals CSP en SRI helpen maar dekken alleen niet het hele aanvalsoppervlak. Ze voeren vrijelijk scripts van derden uit, bieden aanvallers veel signalen om mensen van scanners te onderscheiden en bieden geen native mechanisme voor continue integriteitsvalidatie.

Vanwege deze beperkingen is één enkele techniek nooit genoeg. cside gebruikt gelaagde modi die elkaar aanvullen:

• Gedragsdetectie in de browser van de bezoeker
• Optionele onderschepping van niet-vertrouwde scripts van derden voor levering
• Scannen wanneer geen codewijzigingen mogelijk zijn, versterkt door real-user intelligence

Dit zorgt ervoor dat cside ziet wat echte gebruikers zien, zelfs wanneer aanvallen gericht, intermitterend of ontworpen zijn om crawlers te vermijden.

De verschillende modi van cside

Direct Mode - Makkelijkst

We draaien een lichtgewicht gedragsdetectie-engine direct in de browser van de gebruiker en fetchen dezelfde scripts zelf voor verificatie.

• Geen verkeersomleiding (tenzij je een script specificeert dat je wilt dat wij serveren)
• Geen toegevoegde latentie
• Slechts één script-tag toe te voegen aan je site

Direct Mode geeft onmiddellijke monitoring en integriteitscontroles, zonder je leveringspad te wijzigen.

Gatekeeper Mode - Veiligst

Gatekeeper plaatst cside tussen niet-vertrouwde scripts van derden en je gebruikers, maar alleen voor de scripts die jij kiest.

• We inspecteren en blokkeren optioneel kwaadaardige script-payloads in real-time
• We onderhouden volledige historische payload-records voor forensics en compliance
• Gatekeeper verbetert vaak prestaties door cachinggedrag en kan niet-vertrouwde scripts vastleggen

Deze modus biedt de sterkste beveiligingsgaranties beschikbaar voor dynamische scriptomgevingen. Vermindert de afhankelijkheid van de browser en gebruikt de 'gatekeeper' als een extra service om scriptacties te detecteren.

Scan Mode - Snelst

Als je het cside-script niet kunt toevoegen, vallen we terug op scannen.

Anders dan traditionele scanners wordt onze detectie-engine aangedreven door threat intelligence geleerd van miljarden echte gebruikerssessies over duizenden sites.

Scan Mode is geen vervanging voor real-user monitoring, maar het biedt betekenisvolle bescherming wanneer codewijzigingen nog niet mogelijk zijn.

Waarom Scanners real-world aanvallen missen

// Illustratieve pseudo-logica; niet bedoeld voor productie of misbruik.
const CLOUD_ASNS = new Set([
// Veelvoorkomende Cloud-provider ASN's. 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 netwerkinfo 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 draaien, inclusief eenvoudige PaaS-platforms die gratis kunnen worden gedraaid zonder creditcardinformatie en/of traceerbaarheid naar de kwaadwillende.

Wat het bovenstaande script doet is vrij eenvoudig. Wanneer een verzoek wordt gedaan vanaf een cloudprovider, serveer een schoon script. Elk ander verzoek krijgt een slecht script.

Natuurlijk kan de kwaadwillende meer logica toevoegen. Zoals, serveer het slechte script alleen aan 5% van de verzoeken en als de developer tools gesloten zijn. Wat het moeilijker maakt om te detecteren door handmatige beoordeling.

Reflectiz kan stellen 'maar we scannen vanaf verschillende locaties en verschillende user agents'.

Ten eerste kunnen we niet verifiëren of dat waar is.

Ten tweede kunnen kwaadwillenden het omgekeerde doen en alleen menselijke IP-adressen targeten, de IPv4-webspace omvat 4,3 miljard IP-adressen. Geen scanner kan het niveau van entropie nauwkeurig fabriceren dat je gebruikers gecombineerd natuurlijk zullen hebben. Kunstmatig gedrag is geen menselijk gedrag.

Het gebruik van een residential proxy om te lijken op een normale residentiële gebruiker zal waarschijnlijk geen significant verschil maken. Een kwaadwillende kan nog steeds het gebruik van een residential proxy detecteren en/of zoeken naar basisindicatoren door paginatijden te timen, te controleren hoe selectors worden benaderd, schermformaten en alle factoren combineren in een vergelijkingsboom om mismatches te detecteren tussen UserAgent, gebruikt besturingssysteem door de TCP-pakketindicatoren te controleren enz.

Onafhankelijk onderzoek bevestigt scannerbeperkingen

Onafhankelijk onderzoek toont consequent aan dat scanner-gebaseerde client-side beveiliging geen gelijke tred kan houden met moderne, dynamische browser-side bedreigingen. Branche-analyse van ISACA bevestigt dat traditioneel scannen risico's niet aanpakt die exclusief tijdens runtime in de browser van de gebruiker optreden, terwijl academische studies aantonen dat crawlers en black-box scanners routinematig DOM-gebaseerde kwetsbaarheden, dynamische uitvoeringspaden en voorwaardelijke malware ontworpen om geautomatiseerde tools te ontwijken missen (bijv. https://arxiv.org/abs/1410.4207, https://arxiv.org/abs/2004.06292).

Aanvullend onderzoek benadrukt wijdverbreide false negatives vanwege moderne anti-bot ontwijkingstactieken (https://arxiv.org/abs/2212.12308).

In contrast tonen onafhankelijke evaluaties van runtime-bescherming inclusief RASP-gefocust onderzoek (https://en.wikipedia.org/wiki/Runtime_application_self-protection) aan dat real-time monitoring veel effectiever is in het detecteren en blokkeren van bedreigingen die scanners nooit observeren.

Real-world breach-analyses (British Airways, Ticketmaster, Newegg, Polyfill[.]io en anderen) bevestigen verder dat aanvallers opzettelijk kwaadaardige scripts alleen aan echte gebruikers leveren onder specifieke geolocatie-, timing- en apparaatcondities, wat ervoor zorgt dat scanners de payload nooit zien.

Collectief valideren deze bronnen dat continue, real-time browsermonitoring de enige betrouwbare manier is om moderne client-side supply-chain en JavaScript-gebaseerde aanvallen te detecteren, terwijl scanner-only tools inherente blinde vlekken achterlaten.

Enkele aanvalsmethoden die worden gebruikt om scanner-gebaseerde detecties te vermijden:

Geofenced aanvallen

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

Waarom scanners ze missen:

• Scanners, crawlers en "agent-less" tools draaien bijna altijd vanaf cloud-provider IP's of bekende proxy-bereiken.
• Aanvallers kunnen gemakkelijk een lijst van cloud-ASN's onderhouden en vermijden kwaadaardige payloads te sturen naar die IP's.
• Als gevolg 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 echte gebruikersbrowsers, op echte residentiële en mobiele netwerken.
• Als een script zich kwaadaardig gedraagt voor een echte gebruiker, kan cside het gedrag detecteren, en in gatekeeper-modus 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 je 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-less' oplossingen komen van een reeks voorspelbare User-Agent strings. Ze emuleren zelden mobiele apparaatheaders.

En in de zeldzame gevallen dat een scanner zijn User-Agents wijzigt, komt de agent meestal niet overeen met de daadwerkelijke verzoek-payloads. Scanners draaien meestal op Linux-gebaseerde besturingssystemen, wat betekent dat een kwaadwillende op basis van het TCP-verzoekpakket zal opmerken welk besturingssysteem daadwerkelijk wordt gebruikt. Wat ertoe leidt dat de kwaadaardige payload niet naar de scanner wordt gestuurd omdat Linux zelden door een echte menselijke gebruiker wordt gebruikt.

Waarom cside's benadering hier het beste werkt: we detecteren gedrag in de browser en onze gatekeeper kan als afschrikmiddel fungeren. Als we de kwaadaardige payload niet zien, kreeg je gebruiker ook niet de kwaadaardige payload. We zoeken constant naar aanvallen terwijl ze worden uitgevoerd en samplen geen detecties.

Tijdgebonden aanvallen

Dit zijn aanvallen die alleen op specifieke tijden van de dag worden uitgevoerd. Bijvoorbeeld: na kantooruren wanneer de beveiligingsteams niet aanwezig zijn. Scanners draaien periodiek, dus een tijdgebonden benadering kan gemakkelijk resulteren in het scannen van het goedaardige script, maar niet het kwaadaardige script.

Waarom cside's benadering hier het beste werkt: we detecteren daadwerkelijk gedrag in de browser actief terwijl het gebeurt. We samplen geen detecties, we zijn daar waar je gebruiker is.

Gecloakte of voorwaardelijke code-uitvoering

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

Vaak wordt deze methode gebruikt om de kwaadaardige payload slechts één keer te serveren, zodat een beveiligingsonderzoeker de kwaadaardige payload niet opnieuw zou kunnen vinden. Dit is bijzonder uitdagend omdat developer tools op browsers vaak geen eerdere states van voor het openen van developer tools opslaan. Wat een refresh noodzakelijk maakt.

Een scanner zal nooit in staat zijn om echt gebruikersgedrag te emuleren op dezelfde manier als een echte gebruiker dat zou doen.

Waarom cside's benadering hier het beste werkt: een echte gebruiker voldoet natuurlijk aan deze vereisten en we kijken altijd naar een kwaadaardige actie, of developer tools nu geopend zijn of niet. In theorie kan een kwaadwillende kijken naar onze scriptaanwezigheid op de webpagina en de goedaardige scriptinhoud serveren, maar in dat geval zou je gebruiker geen slachtoffer worden van de aanval, wat onze oplossing effectief laat werken als het tegengif.

Per-sessie dynamische payloads

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

Waarom cside's benadering hier het beste werkt: we draaien actief in de browser terwijl scripts hun acties uitvoeren. Wat resulteert in het detecteren van de kwaadaardige acties terwijl ze gebeuren. Onze optionele gatekeeper-benadering houdt zelfs kopieën van payloads bij, wat je volledige forensische mogelijkheden geeft.

Intermitterende supply-chain vergiftiging

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

Waarom cside's benadering hier beter werkt: of een aanval nu 0,1% van de gebruikers of elke gebruiker target, we monitoren actief de scriptacties.

Aanvallers die technieken combineren

Als een kwaadwillende 5% van de tijd een kwaadaardig script injecteert, na kantooruren alleen naar residentiële IP's in het VK, zal geen scanner het kwaadaardige script kunnen betrappen. En voor een kwaadwillende die een high-value target aanvalt, is dit een lage-inspanning actie. Reflectiz's claims dat ze "20-50%" meer aanvallen detecteren is een ononderbouwde en technisch onwaarschijnlijke bewering zoals hierboven uitgelegd.

De realiteit is simpel: wanneer een scan wordt uitgevoerd, maar de scan gemakkelijk kan worden gedetecteerd, verwacht dat de scan andere resultaten ziet dan echte gebruikers...

Hoe Reflectiz scripts blokkeert

Reflectiz onderscheidt zich door zichzelf te positioneren als een eenvoudig proces om te onboarden zonder de applicatie te beïnvloeden.

Het is correct dat een scanner (of in moderne tijden een agent genoemd) de webprestaties niet beïnvloedt. Het is echter niet noodzakelijkerwijs sneller te implementeren. Integendeel, hun team biedt aan de scanner voor je te implementeren omdat de complexiteit ernstig kan zijn. Veel websites vereisen cookies of sessietokens om bij de betaalpagina's te komen. Die waarden hebben een vervaltijd. Crucialer, zonder een codewijziging te doen of iets aan de website toe te voegen, is het niet mogelijk om een kwaadwillende te blokkeren.

Reflectiz biedt optioneel een client-side script aan om scripts te blokkeren die door zijn klanten zijn gedefinieerd. Je moet uiteindelijk toch een script toevoegen als je scripts wilt blokkeren. Dus dat verslaat het hele "agent-less je hoeft geen code te wijzigen concept". Het feit dat je een script nodig hebt om te blokkeren bewijst ook wat we hier hebben gezegd: een client-side script is noodzakelijk als je daadwerkelijk wilt handelen op een bedreiging. Hun blokkeermogelijkheden zijn beperkt tot het blokkeren van domeinen. Andere leveranciers, waaronder cside, blokkeren gedrag, URL's, hashes en in het geval van cside kunnen zelfs terugdraaien naar veilige versies van scripts.

PCI DSS 4.0.1 en client-side script-integriteit

PCI DSS-compliance is niet zo subjectief als het zou moeten zijn. QSA's hebben persoonlijke visies. Een pass door de ene QSA kan een fail zijn bij een andere. De PCI SSC brengt echter nuttige documentatie uit met suggesties.

Over vereisten 6.4.3 wordt de volgende richtlijn gedeeld: