Web անվտանգություն և OWASP Top 10

01OWASP Top 10-ը պարզ բառերով

OWASP-ը (Open Worldwide Application Security Project) հրապարակում է Top 10-ը՝ հիմնվելով խոցելիությունների իրական տվյալների և համայնքային հարցումների վրա։ 2025-ի հրատարակությունը հետևյալն է. A01 Broken Access Control (օգտատերերը հասնում են տվյալների կամ գործողությունների, որոնց չպետք է հասնեին. SSRF-ն այժմ այս կատեգորիայի մաս է). A02 Security Misconfiguration. A03 Software Supply Chain Failures (խոցելի կամ վտանգված կախվածություններ, build գործիքներ և pipeline-ներ). A04 Cryptographic Failures. A05 Injection (SQL, command, ինչպես նաև XSS). A06 Insecure Design. A07 Authentication Failures. A08 Software or Data Integrity Failures. A09 Security Logging and Alerting Failures. A10 Mishandling of Exceptional Conditions (սխալներ, որոնք «բաց» են ձախողվում կամ մանրամասներ են արտահոսեցնում)։ Օգտագործեք այն իրազեկության և review-ի checklist-ի համար, ոչ թե որպես ամբողջական ստանդարտ. մանրամասն պահանջների համար OWASP-ի Application Security Verification Standard-ը (ASVS) և API Security Top 10-ը ավելի խորն են գնում։

02Broken access control, SSRF և CSRF

Broken access control-ը ամենատարածված լուրջ թերությունն է։ Դասական օրինակ. GET /api/orders/1043-ը վերադարձնում է ցանկացած պատվեր, որովհետև կոդը ստուգում է, որ օգտատերը մուտք է գործել, բայց ոչ այն, որ պատվերը իրենն է։ Սա կոչվում է IDOR (insecure direct object reference)։ Լուծումը սերվերում յուրաքանչյուր request-ի ժամանակ սեփականության կամ իրավունքի ստուգումն է, իդեալում՝ կենտրոնացված policy-ների միջոցով, լռելյայն մերժելով և վերադարձնելով 404 այն օբյեկտների համար, որոնք օգտատերը չի կարող տեսնել։ Server-side request forgery-ն (SSRF) տեղի է ունենում, երբ ձեր սերվերը բերում է օգտատիրոջ տրամադրած URL, օրինակ՝ պատկերի import-ի ժամանակ, և հարձակվողն այն ուղղում է ներքին հասցեների կամ cloud metadata endpoint-ների։ Allow-list արեք host-երն ու scheme-ները, resolve արեք և արգելափակեք private IP տիրույթները և անջատեք redirect-ները։ Cross-site request forgery-ն (CSRF) խաբում է մուտք գործած browser-ին, որպեսզի այն ուղարկի վիճակը փոխող request. պաշտպանվեք SameSite cookie-ներով, CSRF token-ներով և Origin header-ի ստուգմամբ։

• Յուրաքանչյուր օբյեկտի հասանելիություն թույլատրեք սերվերում, ոչ թե UI-ում։
• Լռելյայն մերժեք. թեստավորեք երկրորդ օգտատիրոջ հաշվով։
• URL-ներ բերելու համար. allow-list, private տիրույթների արգելափակում, առանց redirect-ների։

03Injection և XSS

Injection-ը տեղի է ունենում, երբ օգտատիրոջ input-ը մշակվում է որպես կոդ։ SQL injection-ի դեպքում որոնման դաշտը, որը պարունակում է ' OR 1=1 --, փոխում է string concatenation-ով կառուցված query-ի իմաստը՝ արտահոսեցնելով կամ ջնջելով տվյալներ։ Լուծումը պարամետրացված query-ներն են, որտեղ տվյալներն ուղարկվում են SQL-ից առանձին, ինչը աջակցում է յուրաքանչյուր ժամանակակից driver և ORM. զգույշ եղեք raw query helper-ների և դինամիկ սյունակների անունների հետ, որոնց allow-list է պետք։ Նույն սկզբունքը վերաբերում է shell հրամաններին, LDAP-ին և template engine-ներին։ Cross-site scripting-ը (XSS) injection է HTML-ի մեջ. հարձակվողը script է պահում կարծիքում կամ պրոֆիլի անվան մեջ, և այն աշխատում է այլ օգտատերերի browser-ներում՝ գողանալով session-ներ կամ գործողություններ կատարելով։ React-ի նման framework-երը լռելյայն escape են անում output-ը. վտանգավոր գոտիներն են dangerouslySetInnerHTML-ը, v-html-ը, Blade-ի unescaped output-ը և href ատրիբուտների URL-ները։ Հարուստ HTML-ը sanitize արեք ստուգված գրադարանով և որպես երկրորդ շերտ ավելացրեք Content Security Policy։

1import { Pool } from "pg";
2const db = new Pool();
3 
4// Vulnerable: input becomes part of the SQL text
5// db.query("SELECT * FROM users WHERE email = '" + email + "'");
6 
7// Safe: input is sent as a parameter, never parsed as SQL
8export async function findUser(email: string) {
9  const { rows } = await db.query(
10    "SELECT id, email FROM users WHERE email = $1",
11    [email],
12  );
13  return rows[0] ?? null;
14}

04Սխալ կոնֆիգուրացիա և անվտանգ header-ներ

Շատ արտահոսքերի համար խելացի exploit պետք չէ. production-ում միացված թողնված debug mode, public storage bucket, լռելյայն admin գաղտնաբառեր, stack trace-երով մանրամասն սխալի էջեր, directory listing, բաց .env կամ .git պանակ, ինտերնետին բաց բազայի port։ Կանխեք դրանք configuration as code-ով, ըստ միջավայրի կարգավորումներով և deploy pipeline-ում ստուգումներով։ Անվտանգության header-ները պաշտպանություն են ավելացնում browser-ի կողմից։ HTTP Strict Transport Security-ն ստիպում է օգտագործել HTTPS։ Content Security Policy-ն (CSP) browser-ին ասում է, թե script-ների, style-երի և պատկերների որ աղբյուրներն են թույլատրված, ինչը արգելափակում է ներարկված script-ների մեծ մասը. սկսեք report-only ռեժիմից, հետո enforce արեք և 'unsafe-inline'-ի փոխարեն նախընտրեք nonce-ներ կամ hash-եր։ X-Content-Type-Options-ը կանգնեցնում է MIME sniffing-ը, CSP-ի frame-ancestors-ը կանխում է clickjacking-ը, իսկ Referrer-Policy-ն և Permissions-Policy-ն սահմանափակում են, թե ինչ է արտահոսում կամ ինչ է թույլատրված։ Cookie-ները նշեք Secure, HttpOnly և SameSite։

1# nginx: baseline security headers (adapt CSP sources to your app)
2add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
3add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https://cdn.example.com; object-src 'none'; base-uri 'self'; frame-ancestors 'none'" always;
4add_header X-Content-Type-Options "nosniff" always;
5add_header Referrer-Policy "strict-origin-when-cross-origin" always;
6add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
7server_tokens off;

05Գաղտնիքներ, կախվածություններ և supply chain

Գաղտնիքների (API key-եր, բազայի գաղտնաբառեր, ստորագրման բանալիներ) տեղը environment variable-ներում կամ secrets manager-ում է, երբեք repository-ում, կլիենտային bundle-ներում, լոգերում կամ սխալի հաղորդագրություններում։ Յուրաքանչյուր գաղտնիքի տվեք իրեն անհրաժեշտ նվազագույն իրավունքները, բաժանեք դրանք ըստ միջավայրի և ռոտացիա արեք ժամանակացույցով և անմիջապես ցանկացած կասկածելի արտահոսքից հետո. արտահոսած key-ը, որը հնարավոր չէ արագ ռոտացիա անել, նախագծման թերություն է։ Ավելացրեք secret scanning repository-ում և CI-ում, որպեսզի սխալները բռնվեն մինչև push-ը։ Ժամանակակից հավելվածները հիմնականում երրորդ կողմի կոդ են, ահա թե ինչու supply-chain ձախողումներն այժմ առաջին եռյակում են։ Commit արեք lockfile-երը, աշխատեցրեք կախվածությունների audit-ներ (npm audit, composer audit, Dependabot կամ Renovate), ամրագրեք (pin) և վերանայեք CI action-ները, հեռացրեք չօգտագործվող package-ները և կասկածանքով վերաբերվեք նոր package-ներին, որոնք ունեն շատ քիչ download-ներ կամ install script-եր։ Framework-երն ու runtime-երը պահեք աջակցվող տարբերակներում։

06Rate limiting, բոտեր, review-ներ և pentest-եր

Յուրաքանչյուր endpoint, որը կարելի է չարաշահել, սահմանաչափեր է պահանջում. login, OTP և գաղտնաբառի վերականգնման request-ներ, որոնում, կոնտակտային ձևեր, ֆայլերի upload և public API-ներ։ Rate limit արեք ըստ օգտատիրոջ, IP-ի և API key-ի՝ authentication-ի վրա ավելի խիստ սահմաններով. կրկնվող ձախողումներից հետո արգելափակեք կամ դանդաղեցրեք հաշիվները և CAPTCHA կամ proof-of-work challenge ավելացրեք միայն այնտեղ, որտեղ չարաշահումն իրական է։ Առջևում դրված CDN-ը կամ WAF-ը կլանում է ծավալային հարձակումները և արգելափակում հայտնի վատ պատտերնները։ Upload-ները հատուկ ուշադրություն են պահանջում. տիպը ստուգեք ըստ բովանդակության, ոչ թե ընդլայնման, սահմանափակեք չափերը, պաշտպանվեք decompression bomb-երից և ֆայլերը մատուցեք առանձին domain-ից կամ signed հղումներով։ Հետո անվտանգությունը դարձրեք գործընթաց։ Threat model արեք նոր ֆունկցիաները («ի՞նչ կարող է անել այստեղ չարամիտ tenant-ը»), անվտանգության կետեր ներառեք code review-ում, CI-ում աշխատեցրեք SAST և կախվածությունների scan-եր, և խոշոր թողարկումներից առաջ ու պարբերաբար պատվիրեք արտաքին penetration test՝ գտածոները շտկելով ըստ severity-ի։

• Խիստ սահմաններ login-ի, OTP-ի և reset-ի հոսքերի վրա։
• Լոգավորեք անվտանգության իրադարձությունները (ձախողված login-ներ, իրավունքների մերժումներ) և alert ուղարկեք թռիչքների դեպքում։
• Pentest-երը գտնում են այն, ինչ բաց եք թողել. դրանք չեն փոխարինում անվտանգ սովորություններին։

07Գաղտնաբառեր, սեսիաներ և token-ներ՝ ճիշտ ձևով

Գաղտնաբառերը պահիր դանդաղ, memory-hard hash-ով։ OWASP-ի Password Storage Cheat Sheet-ը խորհուրդ է տալիս Argon2id՝ առնվազն 19 MiB հիշողությամբ, 2 իտերացիայով և 1 parallelism-ով, scrypt՝ երբ Argon2id-ն հասանելի չէ, bcrypt՝ միայն legacy համակարգերի համար՝ 10 կամ ավելի work factor-ով և հաշվի առնելով նրա 72 բայթանոց մուտքի սահմանը։ Նոր գաղտնաբառերը ստուգիր հայտնի արտահոսած ցուցակների դեմ՝ տարօրինակ կազմության կանոններ պարտադրելու փոխարեն։ Սեսիաների համար սերվերում պահվող անթափանց պատահական ID-ները պարզ են և ակնթարթորեն չեղարկելի։ Եթե օգտագործում ես JWT-ներ, սերվերում ամրագրիր ընդունելի ալգորիթմը (երբեք մի վստահիր token-ի alg header-ին), վալիդացրու issuer-ը, audience-ը և ժամկետը, access token-ները պահիր կարճակյաց, իսկ refresh token-ները փոխիր ամեն օգտագործման ժամանակ՝ հին refresh token-ի կրկնակի օգտագործումը դիտարկելով որպես գողություն և չեղարկելով ամբողջ «ընտանիքը»։ Login-ից և արտոնությունների փոփոխություններից հետո վերագեներացրու սեսիայի ID-ները՝ session fixation-ը կանխելու համար։

1import argon2 from "argon2";
2 
3// OWASP minimum: Argon2id, 19 MiB memory, 2 iterations, parallelism 1
4export function hashPassword(password: string) {
5  return argon2.hash(password, {
6    type: argon2.argon2id,
7    memoryCost: 19456, // KiB
8    timeCost: 2,
9    parallelism: 1,
10  });
11}
12 
13export function verifyPassword(hash: string, password: string) {
14  return argon2.verify(hash, password); // parameters are read from the hash
15}

08Խիստ Content Security Policy և Trusted Types

Allow-list policy-ները (script-src՝ բազմաթիվ CDN host-երով) հաճախ շրջանցելի են, որովհետև թույլատրված host-երից մեկը կարող է սպասարկել JSONP endpoint կամ հին գրադարան, որը հարձակվողը կարող է չարաշահել։ Խիստ policy-ն փոխարենը հենվում է nonce-ների կամ hash-երի վրա․ սերվերը յուրաքանչյուր պատասխանի համար գեներացնում է նոր պատահական nonce, դնում այն յուրաքանչյուր օրինական script tag-ի վրա և header-ում։ 'strict-dynamic'-ի ավելացումը թույլ է տալիս աշխատել նաև վստահելի script-ի կողմից բեռնված script-ներին, այնպես որ tag manager-ներն ու bundler-ները շարունակում են աշխատել, իսկ առանց nonce-ի ներարկված markup-ը արգելափակվում է։ Համադրիր այն object-src 'none'-ի և base-uri 'none'-ի կամ 'self'-ի հետ։ DOM-based XSS-ի համար Trusted Types-ը (require-trusted-types-for 'script') ստիպում է բրաուզերին մերժել raw տողերը վտանգավոր sink-երում, օրինակ՝ innerHTML-ում, և կոդը անցկացնել վերանայված sanitising policy-ով։ Նախ թողարկիր report-only ռեժիմում և շտկիր խախտումները։

1Content-Security-Policy:
2  script-src 'nonce-r4nd0mBase64Value' 'strict-dynamic';
3  object-src 'none';
4  base-uri 'none';
5  frame-ancestors 'none';
6  require-trusted-types-for 'script';
7  report-to csp-endpoint

09SSRF խորությամբ․ DNS rebinding և cloud metadata

URL տողում մասնավոր IP-ներն արգելափակելը բավարար չէ։ Հարձակվողներն օգտագործում են այլընտրանքային գրառումներ (տասական կամ IPv6-mapped հասցեներ), redirect-ներ դեպի ներքին host-եր և DNS rebinding, երբ hostname-ը քո ստուգման ժամանակ resolve է լինում հանրային IP-ի, իսկ մի պահ անց, երբ միանում ես, 127.0.0.1-ի կամ 169.254.169.254-ի։ Ամուր պաշտպանությունը hostname-ը resolve է անում մեկ անգամ, յուրաքանչյուր resolve արված հասցե ստուգում արգելված տիրույթների դեմ (loopback, private, link-local, unique local IPv6), հետո միանում է հենց այդ IP-ին՝ ուղարկելով սկզբնական Host header-ը, և նորից ստուգում ամեն redirect-ի ժամանակ կամ անջատում է redirect-ները։ Ավելի լավ է՝ օգտատիրոջ նախաձեռնած բոլոր fetch-երն անցկացրու egress proxy-ով, որը կենտրոնացված կիրառում է policy-ն և հասանելիություն չունի ներքին ցանցերին։ AWS-ում պահանջիր IMDSv2, որի session token-ը պետք է ստացվի PUT հարցմամբ, ինչը արգելափակում է instance credentials-ի դեմ SSRF-ի պարզ փորձերի մեծ մասը։

• Ստուգիր resolve արված IP-ները, ոչ թե URL-ի տեքստը, և միացումն ամրագրիր դրանց։
• Արգելափակիր loopback, RFC 1918, link-local և IPv6 unique-local տիրույթները։
• Օգտատիրոջ նախաձեռնած fetch-երն անցկացրու մեկուսացված egress proxy-ով։

10Cookie-ներ, CORS և բրաուզերի մեկուսացում

Cookie-ի ատրիբուտները էժան, բայց ուժեղ շերտ են։ Secure-ը և HttpOnly-ն սեսիայի cookie-ները հեռու են պահում պարզ HTTP-ից և JavaScript-ից։ SameSite=Lax-ը, որը ժամանակակից բրաուզերներում լռելյայն է, երբ նշված չէ, արգելափակում է cross-site POST-երի մեծ մասը․ Strict-ն օգտագործիր բարձր զգայուն cookie-ների համար, իսկ None; Secure-ը՝ միայն երբ իսկապես cross-site օգտագործման կարիք ունես։ __Host- prefix-ը ստիպում է Secure, Path=/ և Domain ատրիբուտի բացակայություն, այնպես որ կոտրված subdomain-ը չի կարող վերագրել cookie-ն։ CORS-ը հաճախ սխալ է հասկացվում․ այն մեղմացնում է same-origin policy-ն, այլ ոչ թե պաշտպանում քո API-ն։ Երբեք մի արտացոլիր կամայական Origin արժեքներ Access-Control-Allow-Credentials: true-ի հետ միասին․ պահիր բացահայտ allow-list։ Ավելի ուժեղ մեկուսացման համար Cross-Origin-Opener-Policy: same-origin-ը քո պատուհանը առանձնացնում է cross-origin popup-ներից, իսկ Cross-Origin-Resource-Policy-ն սահմանափակում է, թե որ կայքերը կարող են ներդնել քո ռեսուրսները։

1Set-Cookie: __Host-session=9f1c...; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=3600
2 
3Access-Control-Allow-Origin: https://app.example.com
4Access-Control-Allow-Credentials: true
5Vary: Origin
6 
7Cross-Origin-Opener-Policy: same-origin
8Cross-Origin-Resource-Policy: same-site