מפרט בדיקות אבטחה לאפליקציית ווב: מה בודקים, באיזה סדר, ומתי זה מוכן לפרודקשן

בדיקת אבטחה בלי רשימה סגורה מראש היא סיור. בודקים את מה שנזכרים בו, מפספסים את מה שלא, ובסוף אין דרך לדעת מה נבדק ומה לא. המפרט הזה הוא הרשימה שלפיה אנחנו בודקים: מה נכלל, איך מסווגים ממצא, ומה צריך להיסגר לפני שמעלים לפרודקשן.

המטרה מנוסחת בשורה אחת: לוודא שאין דרך לקבל גישה לא מורשית למידע או לפעולה במערכת. כל סעיף כאן הוא ניסיון לשבור את השורה הזאת מכיוון אחר.

מה נכנס לתחום הבדיקה

הבדיקה מכסה את האתר בצד הלקוח ובצד השרת, את ה-API על כל נקודות הקצה שלו, את מערכת המשתמשים וההרשאות, מנגנוני התחברות והתנתקות, איפוס סיסמה, אימות דו-שלבי אם קיים, עוגיות וסשנים, מסד הנתונים, העלאת קבצים, שליחת מיילים והודעות SMS, אינטגרציות חיצוניות, מנגנוני תשלום אם קיימים, ממשק הניהול, תשתית השרתים והענן, חשיפת מידע דרך שגיאות, כותרות אבטחה ו-TLS, ומנגנוני היומן והביקורת.

מה שלא נמצא ברשימה הזאת לא נבדק, וזה צריך להיאמר במפורש בדוח.

הזדהות

הבדיקה בשכבת ההזדהות מנסה שלושה דברים: להיכנס בלי פרטים תקינים, להשיג פרטים תקינים בכוח, ולהחזיק גישה אחרי שהיא כבר אמורה להיסגר.

• עקיפת מסך ההתחברות
• Brute force ו-Credential stuffing
• הגבלת קצב ונעילת חשבון
• חוזק סיסמאות ותהליך איפוס סיסמה
• ניחוש של אסימון או קוד חד-פעמי (OTP prediction)
• שימוש חוזר בקוד חד-פעמי ותפוגה שלו
• Session fixation ו-Session hijacking
• התחברות ממספר מכשירים במקביל
• ביטול סשנים אחרי התנתקות ואחרי שינוי סיסמה
• אימות JWT ומניפולציה של שדה האלגוריתם
• דליפת אסימונים
• מצב ההרשאות אחרי שינוי משתמש או תפקיד

השורה האחרונה היא זו שנופלת הכי הרבה. הורדת הרשאה למשתמש שיש לו אסימון חתום ותקף לא עושה כלום עד שהאסימון פג, אלא אם יש מנגנון שמבטל אותו מיידית.

הרשאות

זו הבדיקה הקריטית ביותר, וגם זו שסורק אוטומטי כמעט תמיד מפספס. סורק לא יודע איזה מזהה שייך לאיזה חשבון.

• גישה למשאב של משתמש אחר
• IDOR ו-BOLA
• החלפת מזהה משאב בבקשה: מזהה משתמש, חשבון, מסמך או כל ישות אחרת
• מעבר ממשתמש רגיל למנהל
• Privilege escalation
• גישה ל-API ללא הרשאה, וגישה לפעולות ניהול דרך ה-API
• בדיקת הרשאות בכל נקודת קצה בנפרד, לא בדגימה
• ביצוע פעולות שאינן זמינות בממשק, דרך פנייה ישירה ל-API

המשפט האחרון הוא העיקרון: הממשק אינו מנגנון אבטחה. כפתור מוסתר, שדה מושבת ותפריט שלא מוצג הם החלטות תצוגה. הבדיקה מתבצעת מול השרת, לא מול המסך.

הזרקות

• SQL ו-NoSQL
• Command ו-OS command
• LDAP ו-XPath
• Template injection
• Header injection ו-CRLF
• HTML injection

XSS

הרצת סקריפט זר נבדקת בכל מקום שבו קלט של משתמש חוזר החוצה, כולל מקומות שקל לשכוח: מייל יוצא, מסמך שמופק, וקובץ שהועלה.

• Reflected, Stored ו-DOM
• שדות טקסט ופרמטרים בכתובת
• מיילים
• מסמכים וחשבוניות
• העלאת קבצים
• עקיפת מדיניות התוכן (CSP bypass)

CSRF

כל פעולה שמשנה מצב נבדקת מול בקשה שמגיעה מאתר זר: שינוי סיסמה, שינוי פרטי משתמש, יצירת מסמך, מחיקה, שינוי הרשאות ופעולות פיננסיות. יחד איתן נבדקת הגדרת SameSite על העוגיות.

העלאת קבצים

• העלאת קבצי PHP, JS, HTML ו-SVG
• סיומת כפולה, זיוף MIME ועקיפת Content-Type
• Path traversal דרך שם הקובץ
• Zip bomb וקבצים זדוניים
• שמירת קבצים בתוך ה-Web root
• גישה ישירה לקובץ פרטי, ו-IDOR על קבצים
• XSS דרך SVG או HTML
• הגבלת גודל והגבלת סוגי קבצים

Path traversal

../ פשוט, גרסה מקודדת בכתובת, וקידוד כפול. היעד הוא כל דבר מחוץ ל-Web root: קובצי סביבה, קובצי הגדרות, יומנים, קוד מקור וקובצי גיבוי.

API

לכל נקודת קצה, בנפרד: הזדהות, הרשאה, אימות קלט, הגבלת קצב, שינוי פרמטרים, Mass assignment, חשיפת נתונים עודפת, BOLA ו-IDOR, שינוי שיטת ה-HTTP, חשיפת גרסת API, נקודות קצה של דיבאג, חשיפת Swagger או OpenAPI, ו-introspection ב-GraphQL אם קיים.

לוגיקה עסקית

הקטגוריה הזאת לא מכילה חולשות קוד. הקוד עובד בדיוק כפי שנכתב, והבעיה היא מה שנכתב.

• ביצוע פעולה יותר מפעם אחת
• עקיפת מגבלות שימוש, מגבלת משתמשים או מגבלת עסקים
• שינוי מחיר או כמות
• שימוש חוזר בעסקה
• שימוש בקופון מעבר למותר
• יצירת מסמך ללא הרשאה
• מחיקת מסמך שאסור למחוק
• שינוי מסמך אחרי הנפקתו
• Race conditions ו-Double spending

תרחישי המרוץ נבדקים בשליחה מקבילית, לא ברצף. בקשה אחת אחרי השנייה כמעט תמיד עוברת נכון. שתיים באותו רגע הן מה שמגלה את הבעיה.

חשיפת מידע רגיש

נבדק שאין חשיפה של סיסמאות, מפתחות API, אסימונים, סודות, פרטי לקוחות, מידע פיננסי, מידע אישי, פרטי גישה למסד הנתונים, קובצי סביבה, מפות מקור, עקבות שגיאה, כתובות IP פנימיות, ושדות מיותרים בתשובות ה-API.

כותרות אבטחה

HSTS, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, ו-Frame-Ancestors או X-Frame-Options. על העוגיות: Secure, HttpOnly ו-SameSite.

HTTPS ו-TLS

HTTPS בלבד, הפניה אוטומטית מ-HTTP, הגדרת TLS ותקפות התעודה, גרסאות TLS וצפנים חלשים, תוכן מעורב, וכל מידע שעדיין עובר ב-HTTP.

הגבלת קצב וניצול לרעה

הגבלת קצב נבדקת על ההתחברות, ההרשמה, איפוס הסיסמה, הקוד החד-פעמי, שליחת SMS ומייל, ה-API, יצירת מסמכים, העלאת קבצים וכל פעולה יקרה במעבד או במסד הנתונים. יחד עם זה נבדקת האפשרות למנוע שירות ברמת האפליקציה, בלי נפח תעבורה גדול.

מסד הנתונים

הזרקות SQL, הרשאות המשתמש שמולו רצה האפליקציה, חשיפה של המסד לאינטרנט, הצפנה, ניהול סודות, עיקרון ההרשאה המזערית, גיבויים, גישה ישירה למסד, והצפנת שדות רגישים.

ממשק ניהול

עקיפת התחברות, Privilege escalation, גישה ל-API הניהולי, שינוי תפקיד, יצירת מנהל, מחיקת משתמש, שינוי נתוני משתמש, ייצוא מידע, גישה ליומני ביקורת, וגישה דרך כתובת ישירה בלי מעבר בממשק.

אינטגרציות חיצוניות

OAuth, התחברות דרך Google או Microsoft, ספקי תשלום, ספקי מייל ו-SMS, Webhooks, מפתחות API, אימות חתימה, מתקפות שידור חוזר (replay), ו-SSRF דרך האינטגרציה.

SSRF

נבדק האם משתמש יכול לגרום לשרת לפנות לכתובת שהוא בוחר: localhost, 127.0.0.1, טווחי IP פנימיים, נקודות קצה של מטא-דאטה בענן, ושירותים פנימיים.

הגדרות שגויות

מצב דיבאג, פרטי גישה ברירת מחדל, הצגת תוכן תיקייה, קובצי גיבוי, נקודות קצה של בדיקה ופיתוח, Swagger פתוח, הודעות שגיאה מפורטות, חשיפת גרסת השרת, שירותים מיותרים, והגדרת CORS.

CORS נבדק בנפרד: הערך של Access-Control-Allow-Origin, שימוש בכוכבית, שילוב של אישורי גישה עם CORS, אימות ה-Origin, מקור null, מקורות שרירותיים, וגישה ל-API מאתר זר.

סשנים

תפוגה, זמן חוסר פעילות, החלפת אסימון, ביטול אסימון, הדגלים Secure, HttpOnly ו-SameSite, Session fixation וסשנים מקבילים.

תלויות

חבילות npm ותלויות של השרת ושל צד הלקוח, CVE מוכרים, חבילות לא מעודכנות, ותלויות עקיפות פגיעות. חבילה עם חולשה בדרגת Critical או High נסגרת לפני הבדיקה הבאה, לא אחריה.

צד הלקוח

חשיפת סודות בקוד JavaScript, מפות מקור, DOM XSS, מה נשמר ב-LocalStorage וב-SessionStorage, מידע רגיש בדפדפן, עקיפת הרשאות שנאכפות רק בצד הלקוח, מניפולציה של בקשות API, וחשיפת משתני סביבה.

כלים אוטומטיים

לפני הבדיקה הידנית רצים OWASP ZAP, Burp Suite, Nuclei, סריקת תלויות, SAST, DAST, סריקת סודות וסריקת TLS. הכלים מוצאים את מה שיש לו חתימה מוכרת, ולא מוצאים חולשת הרשאות או לוגיקה עסקית. הם מקצרים את הבדיקה הידנית ולא מחליפים אותה.

בדיקת חדירה ידנית

הבדיקה הידנית מנסה לעבור את שרשרת ההסלמה במלואה:

לא מזוהה ← משתמש מזוהה ← משתמש אחר ← משתמש בעל הרשאות ← מנהל

כל נקודת מעבר אפשרית מתועדת, גם זו שנחסמה. תיעוד של ניסיון שנכשל הוא מה שהופך את הדוח לשימושי בבדיקה הבאה.

דירוג חומרה

רמה	משמעות
Critical	השתלטות על המערכת, דליפה משמעותית או פגיעה חמורה
High	ניצול משמעותי של המערכת או של מידע רגיש
Medium	פגיעה מוגבלת, או ניצול שדורש תנאים מסוימים
Low	חולשה בעלת השפעה מוגבלת
Informational	המלצת הקשחה בלי ניצול משמעותי

מה נמסר בסוף

תקציר מנהלים, רשימת כל החולשות עם דירוג חומרה לכל אחת, נקודת הקצה או הכתובת המושפעת, תיאור החולשה, התנאים הדרושים לניצול, הוכחת היתכנות, ההשפעה, המלצת תיקון, ראיות וצילומי מסך. אחרי התיקון מתבצעת בדיקה חוזרת, ובסופה רשימה של מה נסגר ומה נשאר פתוח.

תנאי הצלחה

המערכת נחשבת מוכנה כשאין חולשות Critical, אין חולשות High פתוחות, וחולשות Medium טופלו או קיבלו קבלת סיכון מתועדת. בנוסף: ההרשאות נבדקו ברמת ה-API ולא רק בממשק, אין חשיפת סודות, אין דרך להגיע למידע של משתמש אחר, ההזדהות וניהול הסשנים תקינים, הגבלת קצב קיימת בנקודות הרגישות, ו-HTTPS וכותרות האבטחה מוגדרים כראוי. הבדיקה החוזרת בוצעה.

הרשימה הזאת היא הבסיס לסקר שסלייט עברה. סקר האבטחה מפרט מה נבדק בפועל ומה נמצא.

שיתוף