უსაფრთხოების აუდიტი
კრიტიკული4 კრიტიკული, 2 მაღალი — საიტი დეველოპერული build-ით მუშაობს
უსაფრთხოების აუდიტი (Pentest) — Doctorium
თარიღი: 2026-05-20
მიდგომა: პასიური აუდიტი production-ზე — აქტიური თავდასხმის გარეშე. ყველა აღმოჩენა დასტურდება იმ HTML/JS-ით, რომელსაც საიტი თვითონ აწვდის ნებისმიერ ვიზიტორს.
სამიზნე: https://doctorium.com/ (Hetzner, Helsinki — 37.27.107.216, nginx 1.18.0 → Express).
შემაჯამებელი
Doctorium.com-ის production-ი დღევანდელი მდგომარეობით საფრთხეშია — ერთიც კი ცალკე აღებული აღმოჩენა საკმარისია სამედიცინო პლატფორმის სანდოობის დასაკარგად, ჯამში კი ეს არის სისტემური უმწიფრობა deployment-ში და უსაფრთხოების მოდელში.
რა ვიპოვეთ ყველაზე საფრთხილო:
- საიტი მუშაობს დეველოპერული ხელსაწყოთი (Vite dev server) პროდუქშენში — გასცემს დეველოპერის ლოკალური კომპიუტერის გზებს (
/@fs/home/kani/App/Doctorium/...) და ხსნის CVE-2025-30208 და მისი მსგავსი vulnerabilities-ის სამიზნე ზონას. - ვერიფიკაციის OTP კოდი თვითონ API-დან ბრუნდება JSON-ში. JS-ი ბრაუზერში ადარებს მას მომხმარებლის შემოყვანილს. ნებისმიერ ცნობილ email-ზე account takeover ტრივიალურია.
- ნამდვილი authentication არ არსებობს —
localStorage.is_auth = trueflag-ი არის ერთადერთი "ნიშანი" რომ მომხმარებელი შესულია. არც JWT, არც session cookie, არც Set-Cookie API-დან. - სრული TypeScript source code საჯაროა source maps-ის გავლით (86 ფაილი, 1.1 MB). DTO-ები, guard-ები, business rule-ები — ყველაფერი ღიად.
- CORS რეფლექსიურია ნებისმიერ Origin-ზე და credentials=true-ით. დღეს ნაკლები რისკი (localStorage auth), მაგრამ cookie-ბის დანერგვის წამს Critical-ად აქცევს.
დამატებით: HTTPS security headers საერთოდ არ არსებობს, პაროლი plaintext-ად იგზავნება password_hash ველში, framework banner-ები ღიად ჩანს, IPv6 records-ი მიუთითებს NameBright-ის parking სერვერზე, საიტი თავის homepage-ზე იყენებს hardcoded test IP-ს (http://31.146.34.166:3203/).
არცერთი აქტიური exploitation არ შესრულდა. ყველა აღმოჩენა მიღებულია ერთი well-formed request-ით endpoint-ზე და საჯაროდ მიწოდებული ფაილების ანალიზიდან.
მთავარი აღმოჩენების ცხრილი
| # | აღმოჩენა | სიმძიმე | მოკლე აღწერა |
|---|---|---|---|
| 1 | OTP კოდი API response-ში | კრიტიკული | ვერიფიკაცია ფაქტობრივად არ ხდება — სერვერი თვითონ აძლევს კოდს კლიენტს |
| 2 | Authentication = localStorage flag | კრიტიკული | ნამდვილი auth (JWT/cookie) საერთოდ არ არსებობს |
| 3 | Vite dev server პროდუქშენში | მაღალი | საიტი მუშაობს დეველოპერული ხელსაწყოთი, /@fs/-ის ჩათვლით |
| 4 | Source maps + TS source code საჯაროდ | მაღალი | 86 ფაილი ხელმისაწვდომი main.js.map-ში |
| 5 | CORS reflects any Origin + credentials | მაღალი | cookie-based auth-ის დანერგვისთანავე Critical |
| 6 | Plaintext password "password_hash" ველში | საშუალო | სქემის სახელი გასცემს backend storage layout-ს |
| 7 | Security headers საერთოდ არ არსებობს | საშუალო | HSTS, CSP, XFO, XCTO, Referrer-Policy არ არის |
| 8 | Server/X-Powered-By banners | დაბალი | nginx 1.18.0 + Express ღიად |
| 9 | Hardcoded test host homepage-ზე | დაბალი | http://31.146.34.166:3203/ ქართული IP, plain HTTP |
| 10 | IPv6 → NameBright parking server | დაბალი | AAAA records მიუთითებენ "Coming Soon" გვერდზე |
| 11 | robots.txt / sitemap.xml / security.txt 302 → / | დაბალი | სამედიცინო პლატფორმაზე security contact არ არსებობს |
| 12 | Placeholder google-site-verification TXT | ინფო | YourUniqueGoogleVerificationCode ჩანაცვლების გარეშე |
დეტალური აღმოჩენები
1. OTP კოდი API response-ში ბრუნდება
სიმძიმე: კრიტიკული
რა არის პრობლემა
როცა მომხმარებელი შემოყავს email-ს რეგისტრაციისთვის, frontend-ი იძახებს POST /api/ai/send-verification-code-ს. სერვერი პასუხში აბრუნებს JSON-ს, რომელშიც წერია სრულად ვერიფიკაციის კოდი (res.Result.code). შემდეგ Angular კოდი ბრაუზერში ინახავს კოდს localStorage-ში და როცა მომხმარებელი შემოყავს კოდს, JS-ი ადარებს მას ===-ით თვითონ — სერვერამდე საერთოდ აღარ მიდის.
ფაქტობრივად: სერვერი თვითონ ეუბნება კლიენტს კოდი, შემდეგ ვერიფიკაცია არ ხდება — ეს თეატრია.
რატომაა ეს პრობლემა
ნორმალური OTP flow: სერვერი იცის კოდი, აგზავნის email-ით, კლიენტი აგზავნის რასაც მომხმარებელი წერს, სერვერი ადარებს თვითონ. Doctorium-ში სერვერი თვითონ ეუბნება კოდს კლიენტს — და კლიენტი ადარებს. ეს არ არის verifikacia, ეს არის ვიზუალური ფასადი.
რა რისკი იქმნება
Account takeover ნებისმიერ ცნობილ email-ზე (კონფიგურაცია staging-ში დასადასტურებელია):
- თავდამსხმელმა იცის ვინმეს email-ი
- გამოაგზავნოს
POST /api/ai/send-verification-code— მიიღოს კოდი response-ში - შემდეგი API call-ით დაასრულოს რეგისტრაცია ან password reset
- მიიღოს წვდომა — მიუხედავად რომ ნამდვილ email-ის ფლობა არ აქვს
ეს არის ერთ-ერთი ყველაზე საფრთხილო ხარვეზი medical platform-ისთვის, რომელშიც პერსონალური და ჯანმრთელობის მონაცემები ინახება.
მტკიცებულება
რას ვუჩვენებთ: main.js:18914 რეგისტრაციის ნაბიჯი 1 — const code = res.Result?.code → localStorage → main.js:19759 ვერიფიკაცია inputCode === expectedCode ფაქტობრივად შესრულდება ბრაუზერში.
რა გავაკეთოთ
- კოდი NEVER არ უნდა იყოს response body-ში (არც create, არც resend ცდის შემთხვევაში)
- გადატანე OTP ვერიფიკაცია სრულად backend-ზე: client უგზავნის
{email, code}→ server ადარებს თვითონ - დაამატე rate limiting (ერთი email-ი დღეში 100+ OTP ვერ მიიღოს)
- დაამატე lockout — N არასწორი ცდის შემდეგ block
- TTL ≤10 წუთი, ერთჯერადი გამოყენება, bind to email + IP
References: CWE-287, CWE-602, OWASP ASVS V2.
2. Authentication = localStorage flag (ნამდვილი auth არ არსებობს)
სიმძიმე: კრიტიკული
რა არის პრობლემა
წარმატებული login-ის შემდეგ Doctorium-ის Angular app-ი ინახავს ბრაუზერში: localStorage.is_auth = true და localStorage.user_data = { ... }. authRedirectGuard სუფთად ამოწმებს ამ flag-ს. არც JWT, არც session cookie, არც Set-Cookie header API-ს მხრიდან.
რატომაა ეს პრობლემა
"შესული" სტატუსი ხდება მთლიანად კლიენტის გადასაწყვეტი. ვინც ბრაუზერში DevTools-ში გახსნის და დაწერს localStorage.setItem('is_auth', true), მისთვის Angular guard-ი დაგუშვებს ნებისმიერ ავტენტიფიცირებულ route-ზე (/chat-ის ჩათვლით).
რა რისკი იქმნება
ეს ფინდინგი დამოკიდებულია იმაზე, server-side შემოწმდება თუ არა ყოველი /api/ai/* request დამოუკიდებლად (staging-ში დასადასტურებელია):
- თუ backend ენდობა
user_id-ს request body-დან (რომელიც ყველა DTO-შია —main.js:2080,19809), მაშინ ეს არის სრულფასოვანი IDOR — ნებისმიერი მომხმარებლის მონაცემები ხელმისაწვდომია სხვა მომხმარებლისთვის. - თუ backend მართებულად authenticate-ს ყოველ call-ს, მაშინ ეს დეგრადირდება UX-only ფინდინგად (route guard მხოლოდ navigation-ისთვის).
OTP bypass-თან (#1) კომბინაციაში ეს არის სრული account takeover chain.
მტკიცებულება
რას ვუჩვენებთ: main.js:18418 — setItem("is_auth", true); main.js:23885 authRedirectGuard ფაქტობრივად ამოწმებს მხოლოდ ამ ერთ ბრიყვს. curl -c cookies.txt https://doctorium.com/ → არანაირი Set-Cookie.
რა გავაკეთოთ
- გასცი HttpOnly, Secure, SameSite=Strict session cookie (ან short-lived JWT HttpOnly cookie-ში) login-ის წამს
- ყოველი
/api/ai/*request მაიძულებლად server-side ავტორიზდეს ამ cookie/token-დან, არასოდეს body-შიuser_id-დან - ჩამოყარე request body-დან
user_id-ის შემოწმება — გაითვალისწინე session subject - response payload-დან ამოაშორე
password_hash,password_saltდა სხვა sensitive ველები
References: CWE-302, CWE-639, OWASP API1:2023 Broken Object Level Authorization.
3. Vite dev server პროდუქშენში
სიმძიმე: მაღალი
რა არის პრობლემა
საიტის HTML-ი ჩატვირთავს <script type="module" src="/@vite/client"></script> და ყველა module URL-ი ფორმის /@fs/home/kani/App/Doctorium/.angular/cache/21.2.8/.... /@fs/ არის Vite dev server-ის სპეციალური route, რომელიც კითხულობს ფაილებს დეველოპერის ლოკალური ფაილური სისტემიდან. main.js-ში 385 occurence-ი არის /@fs/-ის.
რატომაა ეს პრობლემა
Normal workflow: დეველოპერი ნახულობს კოდს ლოკალურად Vite/Angular CLI-ით → მერე გადააქცევს მინიფიცირებულ-ბანდლირებულ dist/ static output-ად → იდება სერვერზე nginx-ის უკან. Doctorium-ის შემთხვევაში ng serve ან vite dev თვითონ პირდაპირ შესრულდება production-ის სერვერზე. ეს არის dev artifact-ის გადანერგვა production-ში, რომელიც დიდი red flag-ია deployment hygiene-ში.
რა რისკი იქმნება
- Information disclosure: გასცემს დეველოპერის OS layout-ს (
/home/kani/App/Doctorium/), username-ს (kani), Angular ვერსიას (21.2.8). - CVE exposure: Vite-ის dev server-ს აქვს
/@fs/path-traversal CVE-ების ისტორია (CVE-2024-31207, CVE-2025-30208). მაშინაც კი თუ patch-ი დადებულია, ეს endpoint საჯაროდ რომ არ უნდა იყოს. - HMR/WebSocket-ის endpoint-ები ხილულია — სხვა dev artifacts-ი (database snapshots, .env file-ები, internal docs) შესაძლოა ცოცხალი იყოს მის გვერდით.
- 3.6 MB-იანი unminified bundle — load-ი ნელია, კოდი წაუშლელ-ი console.log-ებითა და ქართული კომენტარებით.
მტკიცებულება
რას ვუჩვენებთ: production-ის HTML იძახებს /@vite/client-ს და /@fs/home/kani/App/Doctorium/...-ს — დეველოპერული მისამართები, რომელიც პროდუქცია საიტზე არ უნდა არსებობდეს.
რა გავაკეთოთ
- შეცვალე deployment process:
ng build --configuration=production→ staticdist/output → nginx ან CDN. NEVERng serve/vite serveპროდუქციაში. - nginx-ის წინ დაბლოკე ყველა მისამართი რომელიც იწყება
/@fs/,/@vite/,/@id/,/@ng/-ით (404). - გადააამოწმე ყველა საფეხური deployment-ის: რა გადადის სერვერზე, რა process-ი ეშვება.
- ამოაშორე dev cache-ი (
.angular/cache/) production server-დან.
References: CWE-200, CWE-489, CVE-2025-30208, OWASP A05:2021.
4. სრული source maps + TypeScript source content საჯაროა
სიმძიმე: მაღალი
რა არის პრობლემა
https://doctorium.com/main.js.map (1.1 MB) საჯაროდ ხელმისაწვდომია და შეიცავს ყველა 86 ორიგინალური .ts და .html ფაილს sourcesContent ველში. ანალოგიურად app.css.map, styles.css.map და სხვა CSS map-ები — 200 OK.
რატომაა ეს პრობლემა
Source maps საჭიროა debugging-ისთვის. მათი production-ში გასაჯაროება არ არის ნორმა. ისინი მიიღება ხოლმე Sentry-ის ან მსგავსი error platform-ის მიერ, ისე რომ კლიენტს არ უნდა ნახოს. Doctorium-ის შემთხვევაში სრული TypeScript source code საჯაროდ წვდომადია — Doctorium-ის frontend-ი ფაქტობრივად open-source-ია, თუმცა ვერავინ აიღო ეს გადაწყვეტილება.
რა რისკი იქმნება
- DTO/DB სქემის leak: ველების სახელები (
password_hash,password_salt,health_questions_limit,dependent_users_count,is_locked,prcTblUsers...) მკაფიოდ მიუთითებენ database-ის ცხრილებზე და row-level auth model-ზე. - Business logic-ის leak: guard-ები, route table, business rule-ები, API surface — ყველაფერი ღია.
- Reverse-engineering shortcut: რომელიმე bug-ი თუ Doctorium-ში არსებობს კოდის ლოგიკაში, თავდამსხმელი მას წაიკითხავს ორიგინალ TS-ში, არა მინიფიცირებულ JS-ში.
- Internal Georgian კომენტარები ხილულია — დიზაინის ჩანაცვლება და განზრახვა.
მტკიცებულება
რას ვუჩვენებთ: curl -sI https://doctorium.com/main.js.map → HTTP/1.1 200 OK, 86 source ფაილი + sourcesContent array. პირველი ფაილებიდან: src/main.ts, src/app/services/webservices.ts, src/app/services/local-storage.service.ts, src/app/models/struct.ts, src/app/guards/auth-redirect.guard.ts.
რა გავაკეთოთ
- Build-ი
--source-map=false-ით (Angular) ანbuild.sourcemap: false-ით (Vite) production-ისთვის - თუ source maps საჭიროა Sentry-ისთვის → upload-ი error platform-ზე, საჯაროდ 404
hidden-source-mapmode-ი მცირდება source URL comment-ი bundle-ში- ფაილების deployment ცალკე internal-only directory-ში
References: CWE-540, OWASP A05:2021.
5. CORS reflects arbitrary Origin + credentials=true
სიმძიმე: მაღალი
რა არის პრობლემა
Access-Control-Allow-Origin header-ი მიუთითებს რასაც client-ი წერს Origin-ში. Preflight-ის შემთხვევაშიც, GET-შიც. /api/ route-ისთვის ასევე იგზავნება Access-Control-Allow-Credentials: true. ეს ჰგავს Express-ის cors() middleware-ის გამოყენებას origin allowlist-ის გარეშე.
რატომაა ეს პრობლემა
CORS-ის ნორმალური მოდელი: სერვერი ცხადად ეუბნება ბრაუზერს რომელი origin-ებიდან არის OK request-ი. რეფლექსიური CORS = "ნებისმიერი origin OK" — რომელიც credentials-თან კომბინაციაში ნიშნავს, რომ malicious საიტი, რომელიც მომხმარებელმა ეწვია, შეუძლია მისი სახელით request-ი გააკეთოს Doctorium-ის API-ზე.
რა რისკი იქმნება
- დღეს: Medium რისკი. Doctorium-ი იყენებს localStorage-based auth-ს (ფინდინგი #2), რომელიც cross-origin request-ში არ მიდის ავტომატურად, ანუ credentials flag-ს ფაქტობრივად რასაც ცემს არ აქვს.
- მომავალში: ჩაბრუნდება Critical-ად რა წამსაც cookie-based session-ი დაინერგება. ნებისმიერი malicious საიტი მომხმარებლის სახელით შეასრულებს
/api/ai/*call-ებს. - CSRF-ის წინასწარი მზადება — ეს ფინდინგი ფაქტობრივად ხსნის ხარვეზიანი state-ის სატარებას.
მტკიცებულება
$ curl -sI -X OPTIONS https://doctorium.com/ \
-H "Origin: https://attacker.example" \
-H "Access-Control-Request-Method: POST"
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://attacker.example
Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE
$ curl -sI https://doctorium.com/api/
Access-Control-Allow-Credentials: true
რა გავაკეთოთ
Express-ში cors()-ი allowlist-ით:
app.use(cors({
origin: ['https://doctorium.com'],
credentials: true,
methods: ['GET','POST'],
allowedHeaders: ['Content-Type','Authorization'],
maxAge: 86400,
}));
და path-ებზე სადაც credentials არ სჭირდება — საერთოდ ამოაშორე.
References: CWE-942, OWASP A05:2021.
6. Plaintext password იგზავნება password_hash ველში
სიმძიმე: საშუალო
რა არის პრობლემა
რეგისტრაცია და password change request-ი ფაქტობრივად აგზავნის მომხმარებლის უსიტყვო პაროლს password_hash ველში. ქართული კომენტარი კოდში წერია: "ვაწვდით პაროლს (ბექენდი დაჰაშავს)". პასუხის გვერდით ჩანს password_salt: null.
რატომაა ეს პრობლემა
პაროლი TLS-ის ქვეშ თავის ფლანგზე OK-ი, მაგრამ:
- ველის სახელი
password_hashდა მისი წყვილიpassword_saltგასცემს backend storage layout-ს — database-ის ცხრილში დიდი ალბათობით ეს რეალური column-ებია - სქემის leak ეხმარება თავდამსხმელს password cracking-ის სტრატეგიის შერჩევაში (გაიგებს რომ salt არსებობს, რომელი hashing function-ი გამოიყენება)
- დაუდევრობის ნიშანი — სახელის გადარქმევა ფაქტობრივად 30-წამიანი fix-ია, რომელიც არ გაკეთდა
რა გავაკეთოთ
- გადარქმე request field-ი
password-ად - hashing-ი/salting-ი მხოლოდ server-side-ი
- response payload-დან ნუ აბრუნებ ფაქტობრივად ფაქტიურ hash-ს ან salt-ს (კოდიდან ვერ ვხედავთ passive-ად — გადააამოწმე
prcTblUsersselect response)
References: CWE-548 (analog schema leak), OWASP ASVS V2.4.
7. HTTP security headers საერთოდ არ არსებობს
სიმძიმე: საშუალო
რა არის პრობლემა
curl -sI https://doctorium.com/-ის სრული response:
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Wed, 20 May 2026 19:01:48 GMT
Content-Type: text/html;charset=UTF-8
Connection: keep-alive
Vary: Origin
X-Powered-By: Express
არცერთი hardening header-ი: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, COOP/CORP/COEP — არცერთი.
რატომაა ეს პრობლემა
Security headers ცალკე ცალკე "defence-in-depth"-ია, კოლექტიურად მათი არყოფნა ნიშნავს რომ ნებისმიერი XSS, mixed-content, ან clickjacking ხარვეზის impact მძიმდება. სამედიცინო პლატფორმისთვის ეს მისაღები არ არის.
რა გავაკეთოთ
nginx-ის proxy ფლანგზე:
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;
add_header Content-Security-Policy-Report-Only "default-src 'self'; ..." always;
HSTS preload-ი ჩაიდე hstspreload.org-ზე როცა stable გახდება.
References: OWASP Secure Headers Project.
8. Stack banners ღიად ჩანს
სიმძიმე: დაბალი
რა არის პრობლემა
ყოველი response-ი ცემს Server: nginx/1.18.0 (Ubuntu) და X-Powered-By: Express-ს. nginx 1.18.0 = Ubuntu 22.04 LTS-ის package, რომელსაც ცნობილი CVE-ები აქვს.
რა რისკი იქმნება
Fingerprinting-ის გამარტივება — თავდამსხმელი არჩევს კონკრეტულ CVE-ებს (CVE-2021-23017, CVE-2022-41741/41742) ცდის გარეშე.
რა გავაკეთოთ
- nginx.conf-ში:
server_tokens off; - Express-ში:
app.disable('x-powered-by')
References: CWE-200.
9. Hardcoded test host homepage-ზე
სიმძიმე: დაბალი
რა არის პრობლემა
main.js:4280-ში QR widget-ში hardcoded:
qrLink = "http://31.146.34.166:3203/";
ეს IP-ი AS20771 Caucasus Online-შია (Georgia). curl-ი ცემს HTTP/1.1 200 OK-ს იმავე Vite-dev SPA-ით.
რა რისკი იქმნება
- ალბათ დეველოპერის workstation-ი ან staging box-ი — production-ის homepage-დან discoverable
- plain HTTP (cert-ი არ აქვს) — MITM-ის სამიზნე
- დაუდევრობის ნიშანი — production homepage-ი hardcoded development IP-ით
რა გავაკეთოთ
- QR link-ი — real public URL (
https://doctorium.com/appან deep link) - თუ ეს developer workstation-ია → VPN/firewall, არა საჯარო ინტერნეტი
- თუ ეს რეალური prod endpoint-ია → მიეცი დომენი და cert-ი
References: CWE-200.
10. DNS: IPv6 records → NameBright parking server
სიმძიმე: დაბალი
რა არის პრობლემა
$ dig +short doctorium.com AAAA
2600:1f18:4ae:c607:d1d9:565f:b122:bfdb
2600:1f18:4ae:c608:83f8:2f9c:4a61:7b6a
ეს AWS-ის IP-ები NameBright-ის "Coming Soon" parking server-ისთვისაა. IPv6-ის prefer-ად კონფიგურირებული client-ი (ბევრი თანამედროვე ბრაუზერი) მიადგება parking page-ს, არა Doctorium-ის app-ს.
რა გავაკეთოთ
- ამოაშორე stale AAAA records, ან
- დაუდე რეალური IPv6 მისამართები application host-ისთვის და დააწყე HTTP→HTTPS redirect-ი
References: CWE-1188.
11. robots.txt / sitemap.xml / security.txt → 302 → /
სიმძიმე: დაბალი
რა არის პრობლემა
/robots.txt, /sitemap.xml, /.well-known/security.txt — სამივე ცემს 302 Found → location: /. სამედიცინო პლატფორმაზე საჯარო security contact-ი არ არსებობს — researcher-ს არ ექნება სად მისწეროს.
რა გავაკეთოთ
- რეალური
robots.txt-ი (SPA-ის 13 route-ი უნდა იყოს გათვალისწინებული) sitemap.xml(SSR ან pre-render-ის შემდეგ).well-known/security.txt(RFC 9116) authorised contact-ით — სამედიცინო პლატფორმისთვის განსაკუთრებით მნიშვნელოვანი
References: RFC 9116.
12. Placeholder google-site-verification TXT record
სიმძიმე: ინფო
რა არის პრობლემა
$ dig +short doctorium.com TXT
"google-site-verification=YourUniqueGoogleVerificationCode"
TXT record-ი არასოდეს დაიდო რეალური Google Search Console token-ით. ეს არის template-დან copy/paste, რომელიც არ შესრულდა.
რა რისკი იქმნება
უსაფრთხოების პირდაპირი impact-ი არ აქვს, მაგრამ ნიშანია — სხვა template-default-ებიც შესაძლოა ცოცხალი იყოს infrastructure-ის სხვა ნაწილებში. პოლიტიკურად: Search Console verification-ი არასოდეს დასრულდა.
რა გავაკეთოთ
- გადაცვალე რეალური Search Console token-ით ან წაშალე record
- ჩაატარე infrastructure audit სხვა default placeholder-ების მოსაძებნად
API endpoints inventory
Frontend-დან გრეპის შედეგი (main.js-დან) — Doctorium-ის API surface:
განსაკუთრებული ყურადღება შემდეგ endpoint-ებზე:
ai/loginuser,ai/login,ai/send-verification-code,ai/reset-password— auth flowai/prcTblUsers ctrl=0/1/2/3— user CRUD (insert/update/email-check)ai/newgeneratetext,ai/newgenerateanalizi,ai/newgeneratedocs— AI symptom/lab analysis (PHI გადასვლა)ai/getUtmStatsWithoutIP,ai/getEventStatsByDate,ai/getUniqueIpCountByDate— analytics/ops endpoint-ები. Suspected — staging-ში გადააამოწმე admin auth-ი — თუ publicly callable არიან, ლიკავენ business intelligence-ს.api/ai/convertpdftoimage,convertdocxtoimage,convertexceltoimage,updatefile/upload-pdf— file upload-ი (PHI lab analysis path)
დასკვნა და პრიორიტეტები
P0 — public traffic-ის შენარჩუნებამდე უნდა გასწორდეს (ერთი კვირა)
- OTP backend-ზე გადატანე — კოდი response-ში არასოდეს, server-side comparison, rate limit, lockout
- ნამდვილი authentication დანერგე — HttpOnly Secure SameSite=Strict cookie ან JWT cookie-ში; server-side authorization ყოველი
/api/ai/*request-ისთვის - გადააქცი production deployment static build-ად —
ng build→ staticdist/→ nginx; გათიშე/@fs/,/@vite/,/@id/,/@ng/paths - წაშალე source maps production-დან —
--source-map=falseანhidden-source-map; Sentry-ში upload-ი თუ საჭიროა - CORS allowlist-ი — Express
cors()-ი ცხადი origin-ით
P1 — public traffic-ის გახსნის შემდეგ (1 თვე)
- Security headers full set (HSTS, CSP, XFO, XCTO, Referrer-Policy, Permissions-Policy)
- Server/X-Powered-By header-ის შემცირება (
server_tokens off,app.disable('x-powered-by')) password_hashველის გადარქმევა →password- Hardcoded test host (
31.146.34.166:3203) ამოღება ან domain+cert - DNS records-ის გასუფთავება (IPv6, placeholder TXT, CAA records-ის დამატება)
robots.txt,sitemap.xml,.well-known/security.txt— სამედიცინო platform-ისთვის security.txt განსაკუთრებით აუცილებელია
P2 — მუდმივი
- Penetration testing-ის ციკლი (კვარტალური ან 6-თვიური)
- Bug bounty პროგრამა (HackerOne, Bugcrowd) — სამედიცინო პლატფორმაზე responsible disclosure
- Security headers continuous monitoring (Mozilla Observatory, securityheaders.com)
- Build pipeline-ის security review — დევოპერული artifact-ის production-ში გადანერგვის prevention
/api/ai/getUtmStats*,getEventStats*,getUniqueIpCount*endpoint-ების ავტორიზაცია (staging audit)
References
- CWE-287, CWE-302, CWE-602, CWE-639, CWE-540, CWE-489, CWE-942, CWE-200, CWE-548, CWE-1188
- OWASP Top 10 (2021): A02 Cryptographic Failures, A05 Security Misconfiguration, A07 Identification and Authentication Failures
- OWASP API Security Top 10 (2023): API1 BOLA, API2 Broken Authentication
- OWASP ASVS v4: V2 (Authentication), V3 (Session Management), V14 (Configuration)
- RFC 9116 security.txt, RFC 8659 DNS CAA
- OWASP Secure Headers Project: https://owasp.org/www-project-secure-headers/
- Vite security advisories: GHSA-x574-m823-4x7w (CVE-2025-30208)
/@fs/traversal
ეს რეპორტი მომზადებულია მხოლოდ პასიური აუდიტის საფუძველზე. აქტიური exploitation, fuzzing, brute force, ან არსებული მონაცემების შემოწმება არ ჩატარებულა. ყველა "Suspected" აღმოჩენა staging-ში დასადასტურებელია წინასწარი ნებართვით.
