בדיקות תוכנה – אבטחת מידע בזמן פרויקט

איך לשלב בדיקות אבטחה פשוטות בשגרת העבודה של בודקי תוכנה

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

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

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

למה בכלל לחשוב על אבטחה בזמן בדיקות רגילות

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

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

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

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

להתחיל מלשאול שאלות נכונות

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

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

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

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

בדיקה פשוטה של קלט משתמש

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

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

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

טקסט ארוך מאוד
תווים מיוחדים
קוד HTML פשוט
שילוב של מספרים ואותיות בצורה לא צפויה

המטרה היא לא לבצע מתקפה אמיתית, אלא לראות איך המערכת מגיבה לקלט לא רגיל.

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

בדיקת הרשאות בצורה פשוטה

עוד תחום שבו אפשר לגלות בעיות די בקלות הוא בדיקות הרשאות.

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

האם משתמש רגיל יכול לגשת למסך של מנהל?
האם ניתן לבצע פעולה דרך API גם בלי הרשאות מתאימות?
האם ניתן להגיע לדפים מסוימים דרך URL ישיר?

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

זו דוגמה קלאסית למשהו שקל מאוד לפספס אם לא חושבים עליו בזמן הבדיקות.

תשומת לב להודעות שגיאה

עוד נקודה קטנה אך משמעותית היא הודעות שגיאה.

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

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

המידע הזה אולי נראה תמים, אבל הוא יכול לעזור מאוד למישהו שמנסה להבין איך המערכת בנויה.

לכן בזמן בדיקות אני משתדל לשים לב במיוחד למה שקורה כאשר משהו נכשל.

בדיקה בסיסית של ניהול סשן

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

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

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

לשלב אבטחה כחלק מהחשיבה, לא כשלב נפרד

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

במקום לשאול רק:
"האם הפיצ'ר עובד?"

אפשר לשאול גם:
"האם יש דרך להשתמש בו בצורה שלא התכוונו אליה?"

לעיתים קרובות, השאלה הקטנה הזאת מובילה לגילויים מעניינים.

אבטחה מתחילה בהרגלים קטנים

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

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

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

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