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

‫Standard-legacy,‏ Premium ו-Enterprise (יצא משימוש) חבילות שירות

חבילת השירות Security Command Center Enterprise תושבת ב-21 במאי 2027. אם הארגון שלכם משתמש ברמת השירות Enterprise, הארגון יעבור אוטומטית לרמת השירות Premium ב-21 במאי 2027 או אחרי התאריך הזה. אם יש לכם שאלות, אתם יכולים לפנות לנציג החשבון או לGoogle Cloud מומחה מכירות.

בדף הזה מוסבר איך לפרש את הממצאים של 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, אפשר לעיין במאמר Mitigate OWASP Top 10:2025 onGoogle Cloud.

XSS

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

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

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

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

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

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

XSS angular callback

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

פרצת אבטחה XSS‏ (cross-site scripting) במודולים של 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. לדוגמה: <input type="password">. במאפיין הזה מוסתרים התווים שהמשתמש מזין בשדה הסיסמה.

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

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

כדי לפתור את הממצא הזה, צריך לוודא שהדומיין הבסיסי (root) הצפוי הוא חלק מהערך של הכותרת 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

Web Security Scanner יכול למצוא שמשאב נטען שלא תואם לכותרת ה-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

יכול להיות ש-Web Security Scanner ימצא שהתגובה כוללת כותרות תגובה כפולות שקשורות לאבטחה עם ערכים סותרים. ההתנהגות של חלק מכותרות ה-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 ימצא נקודת חולשה של זיהום אב טיפוס באפליקציית אינטרנט שהוקצו למאפייני האובייקט שלה ערכים שניתנים לשליטה על ידי התוקף. תוקפים יכולים ליצור קלט שגורם לאפליקציה להיות פגיעה לפרצת אבטחה XSS‏ (cross-site scripting) או לפגיעויות אחרות בצד הלקוח.

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

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

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

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

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

Web Security Scanner מוודא שכותרת ה-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.

חסר כותר 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

Web Security Scanner מוודא שהכותרת 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.

אימות הבעיה

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

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

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

   מעבר אל Web Security Scanner

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

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

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

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

   • Cross-site scripting: אחרי לחיצה על Reproduction URL, מופיע חלון קופץ ריק בדפדפן, מה שמצביע על כך שהסריקה הצליחה להחדיר קוד לא מזיק לסקריפט.
   • ספרייה לא עדכנית: אחרי שמזינים את כתובת ה-URL הפגיעה, מוצג דף עם הטקסט Exploited (נוצלה), שמציין שהסריקה הצליחה להחדיר קוד לא מזיק לסקריפט.
   • תוכן מעורב אם מזינים את כתובת ה-URL של דף HTTPS ומוחזרת אזהרה לגבי פגיעות של תוכן מעורב. בדוח הממצאים מופיע המשאב הפגיע בקטע כתובת ה-URL של המשאב שמוצג באמצעות HTTP.
   • החדרת Flash: יכול להיות ש-Web Security Scanner יחזיר ממצאים בקטגוריה הזו, אבל רוב הדפדפנים המודרניים מוגנים מפני החדרה של 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 שהתרחשה.