CSP foar Pentesters: Understanding the Fundamentals

Wêrom elke Pentester moat behearskje ynhâldsbefeiligingsbelied

Ynhâldbefeiligingsbelied (CSP) is ien fan 'e meast krityske ferdigeningsmeganismen fan browserside wurden tsjin cross-site scripting (XSS), data-ynjeksje en clickjacking oanfallen. Dochs by penetraasjetesten, bliuwe CSP-headers ien fan 'e meast ferkeard konfigureare - en ferkeard begrepen - befeiligingskontrôles. In 2024-stúdzje dy't mear dan 1 miljoen websiden analysearre fûn dat mar 12,8% CSP-headers hielendal ynset, en fan dy befette hast 94% op syn minst ien beliedsswakke dy't koe wurde eksploitearre. Foar pentesters is it begripen fan CSP net opsjoneel - it is it ferskil tusken in beoardieling op oerflaknivo en in rapport dat de feiligensposysje fan in kliïnt eins fersterket.

Oft jo beoardielingen fan webapplikaasjes útfiere, bug-bounty-jacht dogge, of feiligens bouwe yn in bedriuwsplatfoarm dat gefoelige klantgegevens behannelet, CSP-kennis is fûneminteel. Dizze hantlieding brekt út wat CSP is, hoe't it wurket ûnder de motorkap, wêr't it mislearret, en hoe pentesters systematysk swak belied kinne evaluearje en omgean.

Wat ynhâldbefeiligingsbelied eins docht

Yn har kearn is CSP in deklaratyf befeiligingsmeganisme dat wurdt levere fia in HTTP-antwurdkoptekst (of minder faak, in tag). It ynstruearret de browser hokker boarnen fan ynhâld - skripts, stilen, ôfbyldings, lettertypen, frames, en mear - binne tastien te laden en út te fieren op in bepaalde side. As in boarne it belied skeint, blokkearret de browser it en meldt de oertrêding opsjoneel oan in spesifisearre einpunt.

De oarspronklike motivaasje efter CSP wie om XSS-oanfallen te beheinen. Tradysjonele XSS-defensjes lykas ynput-sanearring en útfierkodearring binne effektyf, mar bros - in inkele miste kontekst of kodearringflater kin de kwetsberens opnij ynfiere. CSP foeget in definsje-yn-djipte laach ta: sels as in oanfaller in kweade skript-tag ynjeksje yn 'e DOM, foarkomt in goed ynsteld belied dat de browser it útfiert.

CSP wurket op in witelistmodel. Yn stee fan te besykjen bekende-minne ynhâld te blokkearjen, definiearret it wat eksplisyt tastien is. Al it oare wurdt standert wegere. Dizze omkearing fan it befeiligingsmodel is machtich yn teory, mar yn 'e praktyk is it behâld fan strang belied oer komplekse webapplikaasjes - benammen platfoarms dy't tsientallen yntegreare modules beheare lykas CRM, fakturearring, analytyk en boekingssystemen - notoir lestich.

Anatomy fan in CSP-koptekst: rjochtlinen en boarnen

In CSP-header is gearstald út oanwizings, dy't elk in spesifyk boarnetype kontrolearje. Begryp fan dizze rjochtlinen is essensjeel foar elke pentester dy't it belied fan in doel evaluearret. De wichtichste rjochtlinen omfetsje default-src (de weromfal foar elke rjochtline dy't net eksplisyt ynsteld is), script-src (JavaScript-útfiering), style-src (CSS), img-src (ôfbyldings), connect-src,s ferbining, WebS, ferbining (X), frame-src (ynbêde iframes), en object-src (plugins lykas Flash of Java-applets).

Elke rjochtline akseptearret ien of mear boarne-útdrukkingen dy't tastiene oarsprong definiearje. Dizze fariearje fan spesifike hostnammen (https://cdn.example.com) oant bredere kaaiwurden:

• 'sels' - lit boarnen ta fan deselde oarsprong as it dokumint
• 'gjin' - blokkearret alle boarnen fan dat type
• 'unsafe-inline' - lit ynline skripts of stilen ta (neutralisearret XSS-beskerming effektyf)
• 'unsafe-eval' - lit eval(), setTimeout(string), en ferlykbere dynamyske koade útfiering ta
• 'nonce-{random}' - kinne spesifike ynline skripts tagged mei in oerienkommende kryptografyske nonce
• 'strict-dynamic' - fertrout skripts laden troch al fertroude skripts, negearret host-basearre tastienelisten
• gegevens: - lit gegevens-URI's ta as ynhâldsboarnen

In echte CSP-header kin der sa útsjen: Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.jsdelivr.net 'nonce-abc123'; style-src 'self' 'ûnfeilich-ynline'; img-src *; object-src 'gjin'. As pentester is it jo taak dit belied te lêzen en fuortendaliks te identifisearjen wêr't it sterk is, wêr't it swak is en wêr't it eksploitabel is.

Algemiene CSP-miskonfiguraasjes dy't Pentesters moatte rjochtsje

It gat tusken it ynsetten fan in CSP-header en it ynsetten fan in effektive CSP-header is enoarm. Yn 'e praktyk befetsje it measte belied swakkens yntrodusearre troch ûntwikkeldersgemak, yntegraasjes fan tredden, of ienfâldich misbegryp. Tidens beoardielingen moatte pentesters systematysk kontrolearje op dizze mienskiplike mislearrings.

De meast ferneatigjende ferkearde konfiguraasje is de oanwêzigens fan 'unsafe-inline' yn 'e script-src-rjochtline. Dit inkele kaaiwurd makket it folsleine anty-XSS-foardiel fan CSP yn wêzen nutteloos, om't it de browser mooglik makket om elke ynline