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

‫

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

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 עשויה להשתמש בנתונים מצטברים ואנונימיים כדי לשפר את הביצועים של Web Security Scanner וכדי לנתח מגמות של פגיעויות באתרים. ‫Google לא תשתף מידע על בעיות ספציפיות או על מצב האבטחה של אתר שנסרק עם אף צד שלישי.

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

זהירות: 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 מספקות מידע מפורט על ממצאי פגיעות באפליקציה, כמו ספריות מיושנות, סקריפטינג חוצה אתרים או שימוש בתוכן מעורב.

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

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

ממצאי הסריקה

בקטע הזה מתוארים סוגי הממצאים של 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 תומך בסריקות בהתאמה אישית של אפליקציות שנפרסו עם כתובות URL וכתובות IP ציבוריות שלא מוסתרות מאחורי חומת אש.

קטגוריה	תיאור הממצא	חיפוש קטגוריה	‫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. כדי לפתור את הממצא הזה, צריך לוודא שדומיין הבסיסי (root) הצפוי הוא חלק מהערך של הכותרת 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 יכולה לבצע בה אינטרפולציה. כדי לפתור את הבעיה הזו, צריך לאמת את הנתונים שהמשתמשים סיפקו ולא מהימנים, ולבצע escape לנתונים האלה. הנתונים האלה מטופלים על ידי Angular framework. רמת התמחור: 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 יכולים לקבל ערכים שניתנים לשליטה על ידי התוקף. ההנחה היא שערכים שמוצבים באבות הטיפוס האלה מתורגמים באופן אוניברסלי לפרצות אבטחה XSS‏ (cross-site scripting), או לנקודות חולשה דומות בצד הלקוח, וגם לבאגים לוגיים. רמת התמחור: 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). קליקג'אקינג (clickjacking, שנקרא גם 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 יפעיל אותן. זה עלול להוביל לתוצאות לא רצויות.
• ב-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 סטטית למאזן העומסים, ואז להפנות את התנועה לאפליקציה. מידע על תמחור מופיע במאמר כל המחירים של שירותי הרשת.

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

אימות

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

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

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

הכלי Web Security Scanner ממלא שדות, לוחץ על לחצנים, לוחץ על קישורים ומבצע פעולות אחרות של משתמשים, ולכן צריך להשתמש בו בזהירות, במיוחד אם סורקים משאבי ייצור. יכול להיות ש-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 שלא ייסרקו או ייבדקו. מידע על התחביר זמין במאמר בנושא החרגת כתובות URL.

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

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

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