ידע מעשי של CyberFixCrew

אבטחת טפסי יצירת קשר: מה נאסף, למי נשלח ומה נשמר

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

התחילו משדות שהעסק צריך כדי לטפל בפנייה

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

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

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

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

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

אימות בשרת אינו רק סימון שדה חובה

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

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

OWASP: אימות קלט וגבולותיו

העלאת קובץ מוסיפה גבול גישה ומשאבים

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

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

OWASP: הגנות על העלאת קבצים

דוגמה: הפנייה הגיעה וגם נשלחה לכלי מדידה

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

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

Google Analytics: מניעת העברת מידע מזהה

סיימו בבדיקה של המסלול השלם

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

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

מקור מקצועי: OWASP: אימות קלט וגבולותיומקור מקצועי: OWASP: הגנות על העלאת קבציםמקור מקצועי: Google Analytics: מניעת העברת מידע מזהה

תשובות ברורות

שאלות שעולות בנושא

HTTPS מספיק לאבטחת הטופס?

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

הטופס לא שומר במסד. אין עותקים?

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

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

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

מתקדמים לפי הצורך

הטופס עובד אבל לא ברור לאן המידע מגיע?

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

לתיאום בדיקה ותוכנית טיפול