תיקון ממצאים של Web Security Scanner

בדף הזה מוסבר איך לפרש את הממצאים של Web Security Scanner, לשחזר אותם ולתקן את הבעיות.

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

סיווג נקודות חולשה

‫Web Security Scanner מזהה את הסוגים הבאים של נקודות חולשה:

  • פרצת אבטחה XSS‏ (cross-site scripting)
  • זיוף בקשות בצד השרת
  • החדרת Flash
  • תוכן מעורב
  • ספריות מיושנות או פגיעות
  • מחיקת סיסמאות בטקסט פשוט
  • אימות מקור לא מאובטח
  • כותרות לא תקינות
  • כותרות עם שגיאות איות
  • מאגרי נתונים נגישים
  • הזרקת SQL
  • החדרת XML
  • זיהום אב טיפוס

סיווגים של הגדרות שגויות

Web Security Scanner מזהה את סוגי הבעיות הבאים בהגדרות:

  • כותרת HTTP Strict Transport Security מוגדרת בצורה שגויה
  • חסר כותר Content Security Policy
  • תצורה שגויה של כותרת Content Security Policy
  • כותרת Cross-Origin-Opener-Policy חסרה
  • חסרה הגנה מפני קליקג'אקינג

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

ההשפעה על היומנים

עקבות של סריקות Web Security Scanner מופיעים בקובצי היומן. לדוגמה, Web Security Scanner יוצר בקשות למחרוזות לא רגילות כמו ~sfi9876 ו-/sfi9876. התהליך הזה מאפשר לסריקה לבדוק את דפי השגיאה של האפליקציה. בקשות לדפים שהן לא חוקיות בכוונה מופיעות ביומנים שלכם.

השבתה של הממצאים אחרי התיקון

אחרי שמתקנים נקודת חולשה או הגדרה שגויה, Web Security Scanner לא מגדיר באופן אוטומטי את המצב של הממצא התואם ב-Security Command Center לערך INACTIVE. אלא אם משנים את המצב באופן ידני, המצב של הממצאים שנוצרו על ידי Web Security Scanner ב-Security Command Center נשאר ACTIVE.

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

Web Security Scanner מריץ סריקות מנוהלות מדי שבוע.

מידע נוסף על סריקות של Web Security Scanner זמין במאמר סוגי סריקות.

תיקון הממצאים של Web Security Scanner

בקטע הזה מוסבר איך לטפל בסוגים שונים של ממצאים של Web Security Scanner. אסטרטגיות להגנה מפני מתקפות נפוצות ברמת האפליקציה שמפורטות ב-OWASP Top 10 זמינות במאמר OWASP Top 10 mitigation options on Google Cloud.

XSS

שם הקטגוריה ב-API: XSS

בדיקת הזרקת סקריפטים חוצי אתרים (XSS) ב-Web Security Scanner מדמה מתקפת הזרקה על ידי הוספת מחרוזת בדיקה לא מזיקה לשדות שניתנים לעריכה על ידי המשתמשים, ולאחר מכן ביצוע פעולות שונות של משתמשים. גלאים מותאמים אישית עוקבים אחרי הדפדפן ו-DOM במהלך הבדיקה כדי לקבוע אם ההחדרה הצליחה ולהעריך את הפוטנציאל שלה לניצול.

אם קוד ה-JavaScript שכלול במחרוזת הבדיקה מופעל בצורה תקינה, הוא מפעיל את מאתר הבאגים של Chrome. אם מחרוזת בדיקה יכולה לפעול, אפשר להחדיר ולהריץ JavaScript בדף. אם תוקף ימצא את הבעיה הזו, הוא יוכל להריץ קוד JavaScript לפי בחירתו בתור המשתמש (הקורבן) שלוחץ על קישור זדוני.

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

כדי לטפל בממצא הזה, צריך לאשר אם הבעיה היא פגיעות XSS. לשם כך, צריך לבדוק באופן ידני אם אפשר לעקוף את השינויים במחרוזת הבדיקה. מידע מפורט על אימות הפגיעות הזו זמין במאמר בנושא Cross-site scripting.

יש כמה דרכים לפתור את הבעיה הזו. התיקון המומלץ הוא להשתמש ב-escape לכל הפלט ולהשתמש במערכת תבניות שתומכת ב-auto-escaping מבוסס-הקשר.

XSS angular callback

שם הקטגוריה ב-API: XSS_ANGULAR_CALLBACK

פרצת אבטחה מסוג Cross-site scripting‏ (XSS) במודולים של AngularJS יכולה להתרחש כש-Angular מבצעת אינטרפולציה של מחרוזת שהמשתמש סיפק. החדרת ערכים שסופקו על ידי המשתמשים לאינטרפולציה של AngularJS יכולה לאפשר את המתקפות הבאות:

  • תוקף יכול להחדיר קוד שרירותי לדף שמוצג על ידי הדפדפנים.
  • תוקף יכול לבצע פעולות בשם הדפדפן של הקורבן במקור של הדף.

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

XSS error

שם הקטגוריה ב-API: XSS_ERROR

ממצא XSS_ERROR הוא באג פוטנציאלי של XSS בגלל שבירה של JavaScript. בנסיבות מסוימות, האפליקציה שנבדקת עשויה לשנות את מחרוזת הבדיקה לפני שהדפדפן מנתח אותה. כשהדפדפן ינסה להריץ את מחרוזת הבדיקה ששונתה, סביר להניח שהוא ייכשל ויציג שגיאת הפעלה של JavaScript. השגיאה הזו מצביעה על בעיה בהחדרה, אבל יכול להיות שלא ניתן לנצל אותה.

כדי לפתור את הבעיה הזו, צריך לוודא אם קיימת פגיעות XSS. לשם כך, צריך לבדוק באופן ידני אם אפשר לעקוף את השינויים במחרוזת הבדיקה. מידע מפורט על אימות פרצת האבטחה הזו זמין במאמר בנושא Cross-site scripting.

Server side request forgery

שם הקטגוריה ב-API: SERVER_SIDE_REQUEST_FORGERY

פרצת אבטחה מסוג SERVER_SIDE_REQUEST_FORGERY מאפשרת למשתמש באפליקציית אינטרנט לקבל גישה לנתונים פנימיים על ידי אילוץ שרת לשלוח בקשה (כמו בקשת HTTP) לנקודת קצה מוגבלת של שירות. לדוגמה, תוקף יכול לנצל את הפגיעות הזו כדי לאחזר נתונים משירות המטא-נתונים. Google Cloud

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

Rosetta flash

שם הקטגוריה ב-API: ROSETTA_FLASH

יכול להיות ש-Web Security Scanner ימצא שהערך של פרמטר בקשה משתקף בחזרה בתחילת התגובה, למשל בבקשות שמשתמשות ב-JSONP. הפגיעות הזו נקראת גם הזרקת Flash. בנסיבות מסוימות, תוקף יכול לגרום לדפדפן להריץ את התגובה כאילו היא קובץ Flash שסופק על ידי אפליקציית האינטרנט הפגיעה.

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

Mixed content

שם הקטגוריה ב-API: MIXED_CONTENT

הכלי Web Security Scanner עוקב באופן פסיבי אחרי תנועת ה-HTTP ומזהה מתי מתבצעת בקשה לקובץ JavaScript או CSS דרך HTTP בהקשר של דף HTTPS. בתרחיש הזה, תוקף מסוג 'אדם באמצע' יכול לשנות את משאב ה-HTTP ולקבל גישה מלאה לאתר שטוען את המשאב, או לעקוב אחרי הפעולות שמבצעים המשתמשים.

כדי לפתור את הבעיה הזו, צריך להשתמש בקישורי HTTP יחסיים. לדוגמה, להחליף את http:// ב-//.

Outdated library

שם הקטגוריה ב-API: OUTDATED_LIBRARY

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

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

Struts insecure deserialization

שם הקטגוריה ב-API: STRUTS_INSECURE_DESERIALIZATION

יכול להיות ש-Web Security Scanner ימצא שאפליקציית האינטרנט שלכם משתמשת בגרסה של Apache Struts שחשופה להתקפות של החדרה של פקודות מרחוק. גרסאות Struts שנפגעו יכולות לנתח באופן שגוי כותרת HTTP לא תקינה של סוג תוכן של תוקף. נקודת החולשה הזו מאפשרת להריץ את הפקודות הזדוניות בהרשאות של שרת האינטרנט.

אלה גרסאות Apache Struts עם נקודת חולשה:

  • גרסאות 2.3.x ישנות יותר מ-2.3.32
  • גרסאות 2.5.x מוקדמות יותר מ-2.5.10.1

כדי לפתור את הבעיה הזו, צריך לשדרג את Apache Struts לגרסה העדכנית ביותר.

מידע נוסף על נקודת החולשה ב-Apache Struts זמין ב-CVE-2017-5638.

Cacheable password input

שם הקטגוריה ב-API: CACHEABLE_PASSWORD_INPUT

יכול להיות ש-Web Security Scanner ימצא שבשדה להזנת סיסמה, אפליקציית האינטרנט משתמשת באלמנט <input> שלא מוגדר בו המאפיין type עם הערך password. כתוצאה מכך, יכול להיות שהסיסמה שהמשתמש הזין תישמר במטמון הרגיל של הדפדפן במקום באחסון סיסמאות מאובטח.

כדי לפתור את הבעיה הזו, מוסיפים את המאפיין type לרכיב <input> ומגדירים אותו לערך password. לדוגמה: &lt;input&nbsp;type="password"&gt;. במאפיין הזה מסתירים את התווים שהמשתמש מזין בשדה הסיסמה.

Clear text password

שם הקטגוריה ב-API: CLEAR_TEXT_PASSWORD

יכול להיות ש-Web Security Scanner ימצא שהאפליקציה מעבירה שדה סיסמה בטקסט רגיל. תוקף יכול לצותת לתנועת נתונים ברשת ולרחרח את שדה הסיסמה.

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

  • שימוש באישור TLS/SSL.
  • תמיד צריך להשתמש ב-HTTPS בדפים שכוללים שדות סיסמה.
  • חשוב לוודא שמאפייני הפעולה של הטופס תמיד מצביעים על כתובת URL מסוג HTTPS.

Insecure allow origin ends with validation

שם הקטגוריה ב-API: INSECURE_ALLOW_ORIGIN_ENDS_WITH_VALIDATION

יכול להיות שסורק אבטחת האתר ימצא שנקודת קצה (endpoint) של HTTP או HTTPS באתר מאמתת רק סיומת של כותרת הבקשה Origin לפני שהיא משקפת אותה בתוך כותרת התגובה Access-Control-Allow-Origin. אם האימות לא מוגדר בצורה נכונה, יכול להיות שנקודת הקצה תעניק גישה לדומיין זדוני שיש לו את אותה סיומת כמו לדומיין שנכלל ברשימת ההיתרים. לדוגמה, אם מאמת נקודת הקצה תואם לדומיינים כמו *google.com, יכול להיות שהוא יאפשר גישה בטעות ל-maliciousdomaingoogle.com.

כדי לפתור את הבעיה הזו, צריך לוודא שהדומיין הראשי הצפוי הוא חלק מהערך של הכותרת Origin לפני שמשקפים אותו בכותרת התגובה Access-Control-Allow-Origin. לגבי תווים כלליים של תת-דומיין, מוסיפים נקודה לפני דומיין הבסיס – לדוגמה, .endsWith(".google.com").

Insecure allow origin starts with validation

שם הקטגוריה ב-API: INSECURE_ALLOW_ORIGIN_STARTS_WITH_VALIDATION

יכול להיות שסורק אבטחת האתרים ימצא שנקודת קצה (endpoint) של HTTP או HTTPS באתר אחר מאמתת רק קידומת של כותרת הבקשה Origin לפני שהיא משקפת אותה בתוך כותרת התגובה Access-Control-Allow-Origin. אם האימות לא מוגדר בצורה נכונה, יכול להיות שנקודת הקצה תעניק גישה לדומיין זדוני שיש לו את אותו הקידומת כמו לדומיין שנכלל ברשימת ההיתרים. לדוגמה, אם מאמת נקודת הקצה בודק רק אם הדומיין ששולח את הבקשה מכיל את google.com, יכול להיות שהוא יאשר בטעות גישה ל-google.com.maliciousdomain.com.

כדי לפתור את הבעיה, צריך לוודא שהדומיין הצפוי תואם באופן מלא לערך הכותרת Origin לפני שמשקפים אותו בכותרת התגובה Access-Control-Allow-Origin. לדוגמה, .equals(".google.com").

Session ID leak

שם הקטגוריה ב-API: SESSION_ID_LEAK

יכול להיות ש-Web Security Scanner ימצא מזהה סשן בכותרת הבקשה Referer של בקשות חוצות-דומיין באפליקציית האינטרנט שלכם. דומיינים שמקבלים את Referer יכולים להשתמש במזהה הסשן כדי להתחזות למשתמש (באמצעות האסימון שלו) או כדי לזהות את המשתמש באופן ייחודי.

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

  • ‫HTTPOnly: מאפיין שמונע גישה לקובצי Cookie מסקריפטים בצד הלקוח
  • ‫Secure: מאפיין שמאפשר להעביר קובצי Cookie רק דרך HTTPS

Invalid content type

שם הקטגוריה ב-API: INVALID_CONTENT_TYPE

יכול להיות שסורק אבטחת האתר ימצא שמשאב נטען שלא תואם לכותרת ה-HTTP של סוג התוכן בתגובה. בתרחיש הזה, האפליקציה מחזירה תוכן רגיש עם סוג תוכן לא תקין, או ללא כותרת X-Content-Type-Options: nosniff.

כדי לפתור את הבעיה, צריך לוודא את הדברים הבאים:

  • תגובות JSON מוצגות עם הכותרת Content-Type application/json
  • תשובות רגישות אחרות מוצגות עם סוגי MIME מתאימים
  • הצגת תוכן עם כותרת ה-HTTP‏ X-Content-Type-Options: nosniff

Invalid header

שם הקטגוריה ב-API: INVALID_HEADER

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

הכותרות התקינות מתוארות בקטעים הבאים.

הכותרת Referrer-Policy

מדיניות תקינה של מפנה מכילה אחד מהערכים הבאים:

  • מחרוזת ריקה
  • no-referrer
  • no-referrer-when-downgrade
  • same-origin
  • origin
  • strict-origin
  • origin-when-cross-origin
  • strict-origin-when-cross-origin
  • unsafe-url

הכותרת X-Frame-Options

כותרת X-Frame-Options תקינה יכולה להכיל רק את הערכים הבאים:

  • DENY: איסור של כל המסגור
  • ‫SAMEORIGIN: allow framing if the top-level URL is same origin
  • ALLOW-FROM URL

‫Chrome לא תומך ב-ALLOW-FROM URL. אסור להשתמש בכמה ערכים של X-Frame-Options.

כותרת X-Content-Type-Options

כותרת X-Content-Type-Options תקינה יכולה להכיל רק ערך אחד: nosniff.

כותרת X-XSS-Protection

כותרת תקינה של X-XSS-Protection חייבת להתחיל ב-0 (disable) או ב-1 (enable). רק אם מפעילים את ההגנה, אפשר להוסיף עד שתי אפשרויות:

  • ‫mode=block מציג דף ריק במקום לסנן את ה-XSS
  • ‫report=URL שולח דוחות אל URL

מפרידים בין האפשרויות באמצעות נקודה-פסיק, לדוגמה 1; mode=block; report=URI. חשוב לוודא שאין נקודה ופסיק בסוף.

Misspelled security header name

שם הקטגוריה ב-API: MISSPELLED_SECURITY_HEADER_NAME

יכול להיות ש-Web Security Scanner ימצא שם של כותרת אבטחה עם שגיאת כתיב. אם יש שגיאת כתיב בכותרת האבטחה, היא לא תפעל ותצטרכו לתקן אותה.

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

Mismatching security header values

שם הקטגוריה ב-API: MISMATCHING_SECURITY_HEADER_VALUES

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

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

מאגר נגיש

יכול להיות ש-Web Security Scanner ימצא מאגר GIT או SVN נגיש באפליקציה. התנאי הזה עלול להוביל לדליפות של הגדרות וקוד מקור.

כדי לשחזר את הפגיעות, לוחצים על כתובת ה-URL לשחזור בדוח הממצאים.

XXE reflected file leakage

שם הקטגוריה ב-API: XXE_REFLECTED_FILE_LEAKAGE

יכול להיות ש-Web Security Scanner ימצא נקודת חולשה מסוג XML External Entity (XXE) באפליקציית אינטרנט שמנתחת XML מקלט משתמשים. תוקף יכול לספק קובץ XML שמכיל ישות חיצונית. הגורם החיצוני הזה יכול להפנות לתוכן שהאפליקציה יכולה לגשת אליו – למשל, קבצים במחשב המארח של האפליקציה. כשמנתח ה-XML של האפליקציה מעבד את ה-XML הזדוני, הוא יכול לחשוף את התוכן של קבצים במארח שלו.

כדי לפתור את הבעיה הזו, צריך להגדיר את מנתחי ה-XML כך שלא יאפשרו ישויות חיצוניות.

למידע נוסף על פרצת האבטחה הזו, אפשר לעיין במאמר בנושא עיבוד של XML External Entity (XXE).

SQL injection

שם הקטגוריה ב-API: SQL_INJECTION

יכול להיות ש-Web Security Scanner ימצא פרצת אבטחה של הזרקת SQL. תוקפים יכולים ליצור קלט שמבצע מניפולציה במבנה השאילתה של שאילתת ה-SQL הבסיסית שפועלת בשרת. הקלט הזה מאפשר להם להוציא נתונים ממסד הנתונים, ובמקרים מסוימים גם לשנות את הנתונים. כדי לפתור את הבעיה הזו, צריך להשתמש בשאילתות עם פרמטרים כדי למנוע השפעה של קלט משתמש על המבנה של שאילתת ה-SQL.

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

Prototype pollution

שם הקטגוריה ב-API: PROTOTYPE_POLLUTION

יכול להיות ש-Web Security Scanner ימצא נקודת חולשה של זיהום אב טיפוס באפליקציית אינטרנט שבה מאפייני האובייקט מקבלים ערכים שניתנים לשליטה על ידי התוקף. תוקפים יכולים ליצור קלט שגורם לאפליקציה להיות פגיעה לסקריפטינג חוצה אתרים או לפגיעויות אחרות בצד הלקוח.

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

תיקון ממצאים של טעויות בהגדרות של Web Security Scanner

בקטע הזה מוסבר איך לטפל בבעיות שונות שמתגלות ב-Web Security Scanner.

הגדרה שגויה של HTTP Strict Transport Security

שם הקטגוריה ב-API: HSTS_MISCONFIGURATION

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

  1. מתחילים עם max-age קטן ורק עם includeSubDomains הכללה (ללא preload). דוגמה: max-age=3600; includeSubDomains.
  2. אחרי תקופת צינון קצרה של כשבוע ללא דיווח על בעיות, אפשר להגדיל את הערך של max-age. דוגמה: max-age=604800; includeSubDomains או max-age=2592000; includeSubDomains.
  3. אחרי כ-3 חודשים ללא בעיות מדווחות, מוסיפים את האתר ואת תתי-הדומיינים שלו אל hstspreload.org ומציינים את ההוראה לטעינה מראש. הגדרת ההנחיה preload (טעינה מראש) מאפשרת להטמיע את דרישת ה-HSTS בדפדפן, כך שגורמים זדוניים לא יוכלו לשדרג לאחור את החיבור. הוראת טעינה מראש: max-age=63072000; includeSubDomains; preload.

חסר header של Content-Security-Policy

שם הקטגוריה ב-API: CSP_MISSING

Web Security Scanner מוודא שכותרת מחמירה של Content-Security-Policy עם nonce בלבד נשלחת עם כל תגובת HTTP.

  Content-Security-Policy:
    script-src 'nonce-{random}' 'report-sample';
    object-src 'none';
    base-uri 'none';
    report-uri https://link-to-report-endpoint

הכותרת Content-Security-Policy מוגדרת בצורה שגויה

שם הקטגוריה ב-API: CSP_MISCONFIGURATION

Web Security Scanner מוודא שכותרת Content-Security-Policy מחמירה שמבוססת על nonce בלבד נשלחת עם כל תגובת HTTP.

  Content-Security-Policy:
    script-src 'nonce-{random}' 'report-sample';
    object-src 'none';
    base-uri 'none';
    report-uri https://link-to-report-endpoint

חסרה הכותרת Cross-Origin-Opener-Policy

שם הקטגוריה ב-API: COOP_MISSING

כלי הסריקה לאבטחת אתרים מוודא שהכותרת Cross-Origin-Opener-Policy נשלחת עם כל תגובת HTTP, כולל אחת מההנחיות התקפות:

  • unsafe-none
  • same-origin-allow-popups
  • same-origin

חסרה הגנה מפני קליקג'אקינג

שם הקטגוריה ב-API: CLICKJACKING_PROTECTION_MISSING

כדי למנוע הונאת קליקים, Web Security Scanner מוודא שכותרת X-Frame-Options או Content-Security-Policy נשלחת עם כל תגובת HTTP:

  • אם אתם משתמשים בכותרת X-Frame-Options, צריך להשתמש בהנחיה DENY או SAMEORIGIN.
  • אם אתם משתמשים בכותרת Content-Security-Policy, צריך להגדיר את ההוראה frame-ancestors.

אימות הבעיה

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

  1. עוברים לדף Web Security Scanner במסוף Google Cloud .

    מעבר אל Web Security Scanner

  2. בוחרים פרויקט. יופיע דף עם רשימה של סריקות מנוהלות וסריקות בהתאמה אישית.

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

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

  5. שיטת האימות משתנה בהתאם לקטגוריית הממצא. משתמשים בדפדפן לבדיקה ופועלים לפי ההוראות שבהמשך.

    • Cross-site scripting: בעקבות כתובת ה-URL לשחזור מופיע חלון קופץ ריק בדפדפן, מה שמצביע על כך שהסריקה הצליחה להחדיר קוד לא מזיק לסקריפט.
    • ספרייה לא עדכנית: אחרי שמזינים את כתובת ה-URL הפגיעה, מוצג דף עם הטקסט 'Exploited' (נוצלה), שמציין שהסריקה הצליחה להחדיר קוד לא מזיק לסקריפט.
    • תוכן מעורב אם מזינים את כתובת ה-URL של דף HTTPS ומוחזרת אזהרה לגבי פגיעות של תוכן מעורב. בדוח הממצאים מופיע המשאב הפגיע בקטע כתובת ה-URL של המשאב שמוצג באמצעות HTTP.
    • החדרת Flash: סורק אבטחת האינטרנט עשוי להחזיר ממצאים בקטגוריה הזו, אבל רוב הדפדפנים המודרניים מוגנים מפני החדרה של Flash. סביר להניח שלא ניתן לנצל את הממצאים האלה.
    • Prototype pollution: Follow the URL in the Reproduction URL field and search for changes on the Object.prototype object introduced by the payload, with the following JavaScript snippets.
      • ({}).__secret_injected_property
      • ({}).__defineGetter__.__secret_injected_property
      • ({}).hasOwnProperty.__secret_injected_property

יכול להיות שאכיפה של Content Security Policy‏ (CSP) עדיין תמנע את ההפעלה של קוד JavaScript. במצב הזה, קשה יותר לשחזר את ה-XSS. אם נתקלתם בבעיה הזו, כדאי לבדוק את מסוף יומן הדפדפן כדי לקבל פרטים על הפרת ה-CSP שהתרחשה.