המנגנון לקבלת קבצים מלקוחות הוא נוח, אך אם לא מעצבים אותו כראוי, הוא עלול להפוך לפגיעות חמורות. תוקפים עשויים לנצל את פרוצדורת ההעלאה כדי להריץ קוד שרירותי, לגרום לתפוס מקום בשרת, להפיץ קבצים לא חוקיים ועוד.
איומים נפוצים הם כדלקמן:
העיקרון הבסיסי להגנה הוא "הגנה רב שכבתית". העיצוב המועיל אינו תלוי באמצעי אחד, אלא עוקב אחרי מספר שכבות הגנה.
צריך להגביל סיומות מורשות ולא לקבוע אם לקבל או לדחות על בסיס הסיומת בלבד. יש לבדוק את החותמת של הקובץ (מספר קסם) ולאמת את תוכן הקובץ. יש ליישם עיבוד המונע תקלות כמו סיומות כפולות או תו NULL מבלי לסמוך על כותרות Content-Type.
אין לשמור שמות קבצים שסופקו על ידי המשתמשים כפי שהם. יש להמיר אותם לשמות ייחודיים באמצעות UUID או HASH + חותמת זמן, ולעצב את השם המקורי כמטא-נתון לשמירה נפרדת. יש גם לטפל בתווים מיוחדים ובמגבלות אורך.
קבצים מועלים צריכים להיות מאוחסנים מחוץ לשורש ה-Web, וחשוב למנוע הפעלות ישירות. אם אפשר, יש לאחסן באחסון אובייקטים ייעודי (כגון: S3) ולספק קישור להורדה דרך האפליקציה. יש להגביל את התיקיות כך שאין להן הרשאות הרצה, אלא לקרוא ולכתוב ברמת המינימום.
יש לקבוע גבול לגודל הקובץ, וליישם מגבלות על מספר העלאות בו זמנית ועל קצב העלאות כדי להבטיח את זמינות השירות. במקרה שמקבלים קבצים דחוסים (כגון ZIP), יש לבדוק את כל הקבצים לאחר ההפקה.
יש לבצע סריקת וירוסים מיד לאחר ההעלאה (אם אפשר, עם מנועים מרובים) ולחסל תוכן שולי עבור PDF/Office על ידי CDR (Content Disarm & Reconstruct). הכנת המידע מחדש (טעינה → יצירת קובץ חדש) יכולה להיות יעילה בהסרת נתונים זדוניים מוטבעים.
יש להגן על התקשורת באמצעות TLS (HTTPS) וכלול אמצעי נגד כמו טוקנים של CSRF. יש לכלול בכותרות התגובה Content-Disposition: attachment
ו-X-Content-Type-Options: nosniff
כדי למנוע תקלות בלתי רצויות מהדפדפן.
יש לתעד מי עבד על איזה קובץ ובאיזו שעה, ולהגדיר התרעות עבור התנהגויות חריגות (כמו העלאות תכופות או דחיות רבות). שמירה על HASH עבור שלמות הקובץ היא גם מועילה.
לאחר היישום, יש לבצע בדיקות פגיעות ומתקפה ייחודיות להעלאת קבצים (הכנסת שליפות, מניעת סיומות, מעקפי נתיבים וכו') ולסקור את המערכת מעת לעת.
כאן אני מציג את UploadF (uploadf.com), אשר תומכת גם במחשבים וגם במכשירים ניידים, תומכת גרירה ושחרור, ומאפשרת העלאה של 100 קבצים בבת אחת, היא יחסית נוחה אך בעת עיצוב השירות ישנם מספר נקודות שצריך לשים לב אליהן.
פריטי בדיקה | נקודות לבחינה/ביצוע |
---|---|
הגבלת רשימת סיומות לבנות | מאפשר רק את הסוגים הדרושים. רשימות שחורות יביאו לשימוש תומך בלבד. |
בדיקות MIME/חותם | לאמת אם הסיומת והתוכן תואמים (בדיקת מספר קסם). |
שמות קבצים מחדש | להמיר לשמות UUID או HASH ולנהל את השמות המקוריים כמטא-נתונים. |
הסרת תווים מיוחדים | להסיר או לדחות תווים כגון `/`, `\`, `..`, NULL וכו'. |
מיקום האחסון | לשמור מחוץ לשורש רשת או באחסון אובייקטים. |
הרשאות תיקיות | איסור על הרצה, רמת הרשאות קריאה וכתיבה מינימלית (עקרון ההרשאות המינימליות). |
גודל קובץ מקסימלי/מינימלי | הבהרה לגבי הגבולות ובדיקות לאחר הפקת קבצים דחוסים. |
שליטה בהעלאות בו זמנית | מגבלות פרלליות, בקרת קצב, הגדרות הטיימאוט. |
סריקות וירוסים/CDR | סריקות מיד לאחר ההעלאה וחסימת הצורך במקרים הנדרשים. |
הצפנת תקשורת (HTTPS) | להפוך TLS לחובה (כדי למנוע מתקפות אדם באמצע). |
אמצעי נגד CSRF | להטיל בדיקות מבוססות טוקנים. |
קביעת כותרות תגובה | להוסיף Content-Disposition: attachment , X-Content-Type-Options: nosniff וכו'. |
תיעוד & התרעות | לפקח על פעולות העלאה, ולאותת על חריגות. |
סקירות בטיחות תקופתיות | לבצע בדיקות פגיעות/חדירה מעת לעת. |
מחיקות אוטומטיות של קבצים ישנים | עיצוב למחיקה מוחלטת לאחר תאריך השימור. |
בקרת גישה/הרשאות | ניהול מרושע של זכויות גישה על בסיס משתמשים/קבוצות. |
פונקציה להעלאת קבצים מאפשרת גם נוחות וגם סיכון. על ידי הכללת הגנה רב שכבתית (רשימות לבנות, בדיקות חתימות, הפרדת מקומות אחסון, אמצעי נגד תוכנה זדונית, תיעוד וכו') בעיצוב ההגנה, הסיכון למתקפות יורד משמעותית.
חשוב שהמשתמשים ירגישו שהשירות "קל לשימוש ובטוח". לדוגמה, שירות כמו UploadF (uploadf.com) שמספק אם מענה על עריכת מחיקות נפרדות או קביעת משך אחסון, מעניק רגשת ביטחון.
※ החומרים לעיל הם דוגמאות ממקורות מתי שהמאמר נכתב. למידע מפורט יותר על יישומים או מידע עדכני על איומים, יש לבדוק את המסמכים הרשמיים של כל אחד.