סקירה כללית על Web Security Scanner

‫Standard-legacy,‏ Premium ו-Enterprise service tiers

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

Web Security Scanner מזהה נקודות חולשה אבטחתיות וטעויות בהגדרות באפליקציות האינטרנט שלכם ב-App Engine, ב-Google Kubernetes Engine ‏ (GKE) וב-Compute Engine. הכלי סורק את האפליקציה, עוקב אחרי כל הקישורים במסגרת כתובות ה-URL להתחלה ומנסה להפעיל כמה שיותר קלטים של משתמשים ומטפלי אירועים. הכלי Web Security Scanner תומך רק בכתובות URL ובכתובות IP ציבוריות שלא מוסתרות מאחורי חומת אש.

Web Security Scanner תומך בסביבה הרגילה של App Engine ובסביבות הגמישות של App Engine, במופעים של Compute Engine ובמשאבי GKE.

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

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

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

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

• הערות לגבי השימוש
• שיטות מומלצות

סוגי סריקות

‫Web Security Scanner מספק סריקה מנוהלת ומותאמת אישית של נקודות חולשה באינטרנט עבור אפליקציות אינטרנט ציבוריות של App Engine,‏ GKE ו-Compute Engine.

סריקות מנוהלות

מסלולי שירות Premium ו-Enterprise

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

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

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

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

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

סריקות בהתאמה אישית

‫Standard-legacy,‏ Premium ו-Enterprise service tiers

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

סריקות בהתאמה אישית מוגדרות ברמת הפרויקט.

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

ממצאי הסריקה

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

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

מזהים ותאימות

Web Security Scanner תומך בקטגוריות בOWASP Top Ten, מסמך שמדרג את 10 סיכוני האבטחה הקריטיים ביותר באפליקציות אינטרנט ומספק הנחיות לתיקון שלהם, כפי שנקבע על ידי Open Web Application Security Project‏ (OWASP).

הערה: הקטגוריה A09:2021 Security Logging and Monitoring Failures (בעבר A10:2017 Insufficient Logging & Monitoring) לא נתמכת. הקטגוריה הזו מתארת חוסרים שמאפשרים לתוקפים להישאר ללא זיהוי. בניגוד לתשע הקטגוריות האחרות של OWASP, היא לא מתייחסת לפגיעויות ספציפיות שתוקפים יכולים לנצל. באופן דומה, Web Security Scanner לא יכול לתקוף אפליקציות אינטרנט כדי לעורר תגובה שניתנת לזיהוי. הבעיות שנכללות בקטגוריה הזו מחייבות שיקול דעת אנושי.

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

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

סוגי ממצאים

Web Security Scanner סריקות מותאמות אישית ומנוהלות מזהות את סוגי הממצאים הבאים.

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

קטגוריה	חיפוש תיאור	חיפוש קטגוריה	‫OWASP 2017 Top 10	OWASP 2021 Top 10
Accessible Git repository שם הקטגוריה ב-API: ACCESSIBLE_GIT_REPOSITORY	מאגר Git נחשף לציבור. כדי לפתור את הבעיה הזו, צריך להסיר גישה ציבורית לא מכוונת למאגר Git. רמת התמחור: Premium או Standard פתרון הבעיה	נקודת חולשה	A5	A01
Accessible SVN repository שם הקטגוריה ב-API: ACCESSIBLE_SVN_REPOSITORY	מאגר SVN חשוף לציבור. כדי לפתור את הבעיה הזו, צריך להסיר גישה לא מכוונת לציבור למאגר SVN. רמת התמחור: Premium או Standard פתרון הבעיה	נקודת חולשה	A5	A01
Accessible ENV File שם הקטגוריה ב-API: ACCESSIBLE_ENV_FILE	קובץ ENV נחשף באופן ציבורי. כדי לפתור את הבעיה, צריך להסיר את הגישה הלא מכוונת לציבור לקובץ ENV. רמת התמחור: Premium או Standard פתרון הבעיה	נקודת חולשה	A5	A01
Cacheable password input שם הקטגוריה ב-API: CACHEABLE_PASSWORD_INPUT	סיסמאות שמוזנות באפליקציית האינטרנט יכולות להיטמן במטמון רגיל של הדפדפן במקום באחסון סיסמאות מאובטח. רמת התמחור: Premium פתרון הבעיה	נקודת חולשה	A3	A04
Clear text password שם הקטגוריה ב-API: CLEAR_TEXT_PASSWORD	הסיסמאות מועברות בטקסט רגיל וניתן ליירט אותן. כדי לפתור את הבעיה, צריך להצפין את הסיסמה שמועברת ברשת. רמת התמחור: Premium או Standard פתרון הבעיה	נקודת חולשה	A3	A02
Insecure allow origin ends with validation שם הקטגוריה ב-API: INSECURE_ALLOW_ORIGIN_ENDS_WITH_VALIDATION	נקודת קצה (endpoint) של HTTP או HTTPS חוצת אתרים מאמתת רק סיומת של כותרת הבקשה Origin לפני שהיא משקפת אותה בתוך כותרת התגובה Access-Control-Allow-Origin. כדי לפתור את הבעיה, צריך לוודא שדומיין הבסיס הצפוי הוא חלק מהערך של הכותרת Origin לפני שמשקפים אותו בכותרת התגובה Access-Control-Allow-Origin. לתווים כלליים של תת-דומיין, מוסיפים נקודה לפני דומיין הבסיס – לדוגמה, .endsWith(".google.com"). רמת התמחור: Premium פתרון הבעיה	נקודת חולשה	A5	A01
Insecure allow origin starts with validation שם הקטגוריה ב-API: INSECURE_ALLOW_ORIGIN_STARTS_WITH_VALIDATION	נקודת קצה (endpoint) של HTTP או HTTPS חוצה-אתרים מאמתת רק קידומת של כותרת הבקשה Origin לפני שהיא משקפת אותה בתוך כותרת התגובה Access-Control-Allow-Origin. כדי לפתור את הבעיה הזו, צריך לוודא שהדומיין הצפוי תואם באופן מלא לערך הכותרת Origin לפני שמשקפים אותו בכותרת התגובה Access-Control-Allow-Origin – לדוגמה, .equals(".google.com"). רמת התמחור: Premium פתרון הבעיה	נקודת חולשה	A5	A01
Invalid content type שם הקטגוריה ב-API: INVALID_CONTENT_TYPE	נטען משאב שלא תואם לכותרת ה-HTTP של סוג התוכן בתגובה. כדי לפתור את הבעיה, צריך להגדיר את כותרת ה-HTTP ‏X-Content-Type-Options עם הערך הנכון. רמת התמחור: Premium או Standard פתרון הבעיה	נקודת חולשה	A6	A05
Invalid header שם הקטגוריה ב-API: INVALID_HEADER	כותרת אבטחה מכילה שגיאת תחביר והדפדפנים מתעלמים ממנה. כדי לפתור את הבעיה, צריך להגדיר את כותרות האבטחה של HTTP בצורה נכונה. רמת התמחור: Premium או Standard פתרון הבעיה	נקודת חולשה	A6	A05
Mismatching security header values שם הקטגוריה ב-API: MISMATCHING_SECURITY_HEADER_VALUES	כותרת אבטחה מכילה ערכים כפולים או לא תואמים, ולכן ההתנהגות לא מוגדרת. כדי לפתור את הבעיה הזו, צריך להגדיר את כותרות האבטחה של HTTP בצורה נכונה. רמת התמחור: Premium או Standard פתרון הבעיה	נקודת חולשה	A6	A05
Misspelled security header name שם הקטגוריה ב-API: MISSPELLED_SECURITY_HEADER_NAME	יש שגיאת כתיב בכותרת אבטחה והמערכת מתעלמת ממנה. כדי לפתור את הבעיה הזו, צריך להגדיר בצורה נכונה את כותרות האבטחה של HTTP. רמת התמחור: Premium או Standard פתרון הבעיה	נקודת חולשה	A6	A05
Mixed content שם הקטגוריה ב-API: MIXED_CONTENT	משאבים מוצגים באמצעות HTTP בדף HTTPS. כדי לפתור את הבעיה הזו, צריך לוודא שכל המשאבים מועברים באמצעות HTTPS. רמת התמחור: Premium או Standard פתרון הבעיה	נקודת חולשה	A6	A05
Outdated library שם הקטגוריה ב-API: OUTDATED_LIBRARY	זוהתה ספרייה עם נקודות חולשה ידועות. כדי לפתור את הבעיה, צריך לשדרג את הספריות לגרסה חדשה יותר. רמת התמחור: Premium או Standard פתרון הבעיה	נקודת חולשה	A9	A06
Server side request forgery שם הקטגוריה ב-API: SERVER_SIDE_REQUEST_FORGERY	זוהתה פגיעות של זיוף בקשות בצד השרת (SSRF). כדי לפתור את הבעיה, צריך להשתמש ברשימת היתרים כדי להגביל את הדומיינים וכתובות ה-IP שאליהם אפליקציית האינטרנט יכולה לשלוח בקשות. רמת התמחור: Premium או Standard פתרון הבעיה	נקודת חולשה	לא רלוונטי	A10
Session ID leak שם הקטגוריה ב-API: SESSION_ID_LEAK	כשמגישים בקשה חוצת-דומיין, אפליקציית האינטרנט כוללת את מזהה הסשן של המשתמש בכותרת הבקשה Referer. הפגיעות הזו מאפשרת לדומיין המקבל גישה למזהה הסשן, שאפשר להשתמש בו כדי להתחזות למשתמש או לזהות אותו באופן ייחודי. רמת התמחור: Premium פתרון הבעיה	נקודת חולשה	A2	A07
SQL injection שם הקטגוריה ב-API: SQL_INJECTION	זוהתה פרצת אבטחה פוטנציאלית של הזרקת SQL. כדי לפתור את הבעיה הזו, משתמשים בשאילתות עם פרמטרים כדי למנוע מקלט משתמש להשפיע על המבנה של שאילתת ה-SQL. רמת התמחור: Premium פתרון הבעיה	נקודת חולשה	A1	A03
Struts insecure deserialization שם הקטגוריה ב-API: STRUTS_INSECURE_DESERIALIZATION	זוהה שימוש בגרסה פגיעה של Apache Struts. כדי לפתור את הבעיה הזו, צריך לשדרג את Apache Struts לגרסה העדכנית ביותר. רמת התמחור: Premium פתרון הבעיה	נקודת חולשה	A8	A08
XSS שם הקטגוריה ב-API: XSS	שדה באפליקציית האינטרנט הזו חשוף למתקפת XSS‏ (cross-site scripting). כדי לפתור את הבעיה הזו, צריך לאמת את הנתונים שסופקו על ידי משתמשים לא מהימנים ולבצע בהם escape. רמת התמחור: Premium או Standard פתרון הבעיה	נקודת חולשה	A7	A03
XSS angular callback שם הקטגוריה ב-API: XSS_ANGULAR_CALLBACK	מחרוזת שסופקה על ידי משתמש לא עוברת escape ו-AngularJS יכולה לבצע בה אינטרפולציה. כדי לפתור את הבעיה הזו, צריך לאמת את הנתונים שסופקו על ידי משתמשים לא מהימנים שמטופלים על ידי מסגרת Angular, ולבצע escape לנתונים האלה. רמת התמחור: Premium או Standard פתרון הבעיה	נקודת חולשה	A7	A03
XSS error שם הקטגוריה ב-API: XSS_ERROR	שדה באפליקציית האינטרנט הזו חשוף לפרצת אבטחה XSS‏ (cross-site scripting). כדי לפתור את הבעיה הזו, צריך לאמת את הנתונים שסופקו על ידי משתמשים לא מהימנים ולבצע בהם escape. רמת התמחור: Premium או Standard פתרון הבעיה	נקודת חולשה	A7	A03
XXE reflected file leakage שם הקטגוריה ב-API: XXE_REFLECTED_FILE_LEAKAGE	זוהתה פגיעות מסוג XML External Entity ‏ (XXE). הפגיעות הזו עלולה לגרום לאפליקציית האינטרנט לדלוף קובץ במארח. כדי לפתור את הבעיה הזו, צריך להגדיר את מנתחי ה-XML כך שלא יאפשרו ישויות חיצוניות. רמת התמחור: Premium פתרון הבעיה	נקודת חולשה	A4	A05
Prototype pollution שם הקטגוריה ב-API: PROTOTYPE_POLLUTION	האפליקציה חשופה לזיהום אב טיפוס. הפגיעות הזו מתרחשת כשמאפיינים של אובייקט Object.prototype יכולים לקבל ערכים שניתנים לשליטה על ידי התוקף. ההנחה היא שערכים שמוצבים באבות-טיפוס כאלה מתורגמים באופן אוניברסלי לסקריפטים חוצי אתרים, או לפגיעויות דומות בצד הלקוח, וגם לבאגים לוגיים. רמת התמחור: Premium או Standard פתרון הבעיה	נקודת חולשה	A1	A03
Hsts Misconfiguration שם הקטגוריה ב-API: HSTS_MISCONFIGURATION	זוהתה כותרת HTTP Strict Transport Security‏ (HSTS) בתצורה שגויה. כדי לצמצם באופן משמעותי את הסיכון לשדרוג לאחור ולמתקפות של ציתות בחיבורי HTTP, צריך לפתור את הבעיה בכותרת HSTS שהוגדרה בצורה שגויה. כותרות HSTS מאלצות חיבורים דרך ערוצים מוצפנים (TLS), כך שחיבורי HTTP בטקסט גלוי נכשלים. מידע נוסף על כותרות HSTS רמת התמחור: Premium פתרון הבעיה	הגדרה שגויה	לא רלוונטי	לא רלוונטי
Content Security Policy Header Missing שם הקטגוריה ב-API: CSP_MISSING	זוהתה כותרת תגובת HTTP חסרה של Content Security Policy‏ (CSP). כותרות CSP מפחיתות את הסיכון לניצול של נקודות חולשה נפוצות באינטרנט, במיוחד פרצת אבטחה XSS‏ (cross-site scripting), על ידי מניעת טעינה של סקריפטים או פלאגינים לא מהימנים. מומלץ להשתמש בכותרת CSP מחמירה. מידע נוסף על כותרות CSP רמת התמחור: Premium פתרון הבעיה	הגדרה שגויה	לא רלוונטי	לא רלוונטי
Content Security Policy Header Misconfigured שם הקטגוריה ב-API: CSP_MISCONFIGURATION	זוהתה כותרת תגובת HTTP של Content Security Policy‏ (CSP) שהוגדרה בצורה שגויה. כותרות CSP מפחיתות את הסיכון לניצול של נקודות חולשה נפוצות באינטרנט, במיוחד פרצת אבטחה XSS‏ (cross-site scripting), על ידי מניעת טעינה של סקריפטים או פלאגינים לא מהימנים. מומלץ להשתמש בכותרת CSP מחמירה. מידע נוסף על כותרות CSP רמת התמחור: Premium פתרון הבעיה	הגדרה שגויה	לא רלוונטי	לא רלוונטי
Cross-Origin-Opener-Policy Header Missing שם הקטגוריה ב-API: COOP_MISSING	זוהתה כותרת HTTP חסרה של מדיניות פותחן מרובת מקורות (COOP). ‫COOP הוא מנגנון אבטחה באינטרנט שמגביל את הגישה של דף שנפתח בחלון חדש למאפיינים מהדף המקורי שלו. ‫COOP מספק שכבת הגנה חזקה מפני התקפות נפוצות באינטרנט. רמת התמחור: Premium פתרון הבעיה	הגדרה שגויה	לא רלוונטי	לא רלוונטי
Clickjacking Protection Missing שם הקטגוריה ב-API: CLICKJACKING_PROTECTION_MISSING	זוהתה כותרת תגובה חסרה. כדי למנוע מתקפות clickjacking, צריך להטמיע כותרת תגובה של HTTP כמו X-Frame-Option (XFO) או Content-Security-Policy (CSP). חטיפת קליקים (נקראת גם UI Redress) היא מתקפת אינטרנט שבה התוקפים משנים את הממשק של אתר מטרה, כך שהקורבנות לא מבינים שהם מבצעים פעולה חשובה. מומלץ להטמיע כותרת תגובה של HTTP: קל להשתמש בכותרות XFO, וכותרות CSP מספקות גמישות רבה יותר. – מידע נוסף על כותרות XFO – מידע נוסף על כותרות CSP רמת התמחור: Premium פתרון הבעיה	הגדרה שגויה	לא רלוונטי	לא רלוונטי

הערות לגבי השימוש

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

דברים חשובים נוספים שכדאי לדעת כשמשתמשים ב-Web Security Scanner:

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

מי יכול להריץ סריקת אבטחה?

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

כמה זמן נדרש לסריקת אבטחה?

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

הגבלות על טירגוט

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

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

סריקות של Compute Engine ו-GKE מוגבלות לדומיינים שממופים לכתובות IP חיצוניות סטטיות ששמורות לאותו פרויקט ולכתובות IP חיצוניות סטטיות ששייכות לאותו פרויקט. הוראות להזמנת כתובות IP לפרויקטים מופיעות בקישורים הבאים:

• ‫Compute Engine: שמירת כתובת IP חיצונית סטטית

• ‫GKE: הגדרת שמות דומיינים עם כתובות IP סטטיות

ב-App Engine אין אפשרות למפות כתובות IP סטטיות לאפליקציה. עם זאת, אתם יכולים להשתמש ב-Cloud Load Balancing ובקבוצות של נקודות קצה ברשת ללא שרת כדי לשריין כתובת IP סטטית למאזן העומסים, ואז להפנות את התנועה לאפליקציה. מידע על תמחור זמין במאמר כל המחירים של שירותי הרשת.

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

אימות

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

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

שיטות מומלצות

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

לדוגמה:

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

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

1. הרצת סריקות בסביבת בדיקה מגדירים סביבת בדיקה על ידי יצירת פרויקט נפרד של App Engine וטוענים אליו את האפליקציה והנתונים. אם אתם משתמשים ב-Google Cloud CLI, אתם יכולים לציין את פרויקט היעד כאפשרות בשורת הפקודה כשאתם מעלים את האפליקציה.
2. להשתמש בחשבון בדיקה. צריך ליצור חשבון משתמש שאין לו גישה לנתונים רגישים או לפעולות מזיקות, ולהשתמש בו כשסורקים את האפליקציה. באפליקציות רבות יש תהליך עבודה מיוחד במהלך הכניסה הראשונה של משתמש, כמו אישור תנאים ויצירת פרופיל. בגלל תהליך העבודה השונה, יכול להיות שלחשבון בדיקה של משתמש חדש יהיו תוצאות סריקה שונות מאלה של חשבון משתמש קיים. מומלץ לסרוק באמצעות חשבון שנמצא במצב משתמש רגיל, אחרי השלמת התהליך של הפעם הראשונה.
3. לחסום רכיבים ספציפיים בממשק המשתמש שלא רוצים להפעיל על ידי החלת מחלקת ה-CSS‏ inq-no-click. גורמים מטפלים באירועים שמצורפים לרכיב הזה לא מופעלים במהלך סריקה ובדיקה, לא משנה אם הם JavaScript מוטבע, או שמצורפים באמצעות addEventListener, או שמצורפים על ידי הגדרת מאפיין הגורם המטפל באירועים המתאים.
4. שימוש בנתוני גיבוי. מומלץ לגבות את הנתונים לפני הסריקה.
5. כתובות URL מוחרגות. אתם יכולים לציין תבניות של כתובות URL שלא ייסרקו או ייבדקו. כאן אפשר לקרוא מידע נוסף על התחביר.

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

המאמרים הבאים

• התחלת העבודה עם Web Security Scanner.