בעקבות פרסום מסמך בדיקות מעולה המבוסס על מדריך הבדיקות של OWASP בבלוג של 0xicf
מצ"ב המסמך בתרגום חופשי לעברית: - 61 חוקים מחולקים לקטגטריות שישומום יגדיל את אבטחת האפליקציה .
ניתן להוריד גם את הקובץ בפורמט XLS מפורט מכאן.
איסוף מידע:
1.
צמצום
ככל האפשר הצגת מידע מידע קריטי על רכיבי המערכת
דרך מענה HTTP או HTTP
ERRORS ,מידע המכיל - שם השרת , כתובות IP פנימיות, גרסת מערכת הפעלה ,סוג וגרסת האפליקציה,סוג\גרסת מסד הנתונים יאפשרו לתוקף הבנה ומיקוד ההתקפה.
מור אינפו..
http://technet.microsoft.com/en-us/security/cc242650.aspx = IIS
APACHE:
Open your httpd.conf file using text editor such as vi:
vi httpd.conf
Append/modify config directive as follows:
ServerSignature Off
ServerTokens Prod
Save and close the file. Restart Apache web server:
# /etc/init.d/httpd restart
2.
שגיאות
הנשלחות משרת האפליקציה אל הלקוח ושגיאות מערכת יכילו מנינימום מידע.
4.
יש לכלול
דפי אפליקציה רגישים בקובץ robot.txt ( מניעת סריקה ואינדוקס)
אך דפי גישה קריטיים כגון דפגי גישת ADMIN אין
לכללול בקובץ זה.
דוגמא http://blog.imperva.com./robots.txt
ניהול קונפיגורציה:
5.
יש
להתקין בהקדם האפשר את כל טלאי האבטחה
עבור כל המערכות – שרתים ,אפליקציות , מסדי נתונים וכו
6.
יש לבטל
את כל שיטות הגישה ב HTTP למעט GET ו POST (head,options,put
….) במידה והם לא בשימוש
7.
יש לחסום
גישה לכל משאב לא "ציבורי" non public כדוגמת: אתרים ושרתי גיבוי,שרתי TEST ,STAGE ,אתרי DEMO, QA וכו
9.
יש להסיר
כל חשבונן משתמש ברירת מחדל DEFAULTS מההשרת,האפליקציה ומסדי הנתונים
10. יש לשלוט ולסנן מאפיני HTML e.g. autocomplete,
cache-control, pragma למניעת שמירת מידע רגיש בCACH ( ססמאות session וכו)
If you want to remove the warning entirely, you can use JavaScript to apply the attribute to browsers that support it (IE and Firfox are the important browsers) using someForm.setAttribute( "autocomplete", "off" ); someFormElm.setAttribute( "autocomplete", "off" );
12.
ביטול SSL renegotiation – למניעת התקפות מניעת שירות וMITM .
כלי בדיקה לפגיעות האתר
IIS versions 6 and above are NOT affected by the renegotiation DoS attack since http.sys (http driver on Windows Server) disallows client initiated renegotiation in SSL and sends a TCP RST anytime a client attempts a renegotiation.
13.
צימצום ומיקוד מדיניות הרשאת גישה ממספר דומיינים ( cross domain policy ) (for Flash
crossdomain.xml and for SilverLight
clientaccesspolicy.xml) , ביטול הרשאה גורפת ל * .
קריאה נוספת
הזדהות – authentication
14. שימוש בססמאות חזקות ומורכבות בלבד הן ברמת ה ADMIN והן ברמת הלקוח
16. שימוש ב HTTPS SSL עבור כל תעבורת מידע קריטי כגון ססמאות, כרטיסי אשראי ,מידע אישי
וכו
17. כל בדיקות ההזדהות וההרשאות יתבצעו בצד השרת SERVER
SIDE
19. יש לכפות על המשתמשים שינוי
הסיסמה הראשונית שקיבלו באמצעים כגון מייל או אס אם אס.
20. כל פעילות קריטית במערכת תשמר ביומן ((LOG הן ברמת השרת והן ברמת
האפליקציה.
21. יש לשמור לוג של כל הזדהות טובה וכל הזדהות שגויה (successful and unsuccessful login).
22. יש להציג הודעה ג'נרית עבור כשלון הזדהות: Username and/or Password
is wrong
Session management
25. יש לייצר מזהה חד ערכי חדש ( session id ) עבור כל כניסה למערכת +כניסה מחדש וכן לבטל
את המזהה לאחר ביצוע יציאה מהמערכת.
27. עוגיות ( COOKIES) המשמשות להחזקת SESSION ID – יאובטחו ויוגבלו לשימוש באותו
אתרDOMIAN בלבד.
29. יש להפנות את המשתמש דרך דף 302 לדף
פנימי לאחר הזדהות מוצלחת.
30. יש לאפשר אפשרות יציאה( LOG OUT) בכל דף באתר.
הרשאות,אישורים
31. יש לקחת בחשבון ולמנוע שינוי בערכי פרמטרים בבקשות HTTP GET ו POST ע"י התוקף ע"י ביצוע אימות הקלט הן בצד הלקוח ובעיקר
בצד השרת
32. יש להגביל את הרשאות משתמש המערכת שמריץ את האפליקציה בצד השרת לתקייה ומשאבי האפליקציה בלבד.
33. יש להגביל את גישת משתמש המערכת אך ורק לטבלאות הרלוונטיות לו במסד
הנתונים DB.
34. יש להגביל גישה ל DB רק מכתובת הIP של האפליקציה וע"י שם משתמש יחודי של המערכת.
35. יש לבצע סיננכרוניזציה וזמינות של משאבי מערכת קרטיים למניעת race contrition .
36. יש להגביל למשתמשים ותפקידים גישה לכל אפליקצית ניטור ואיסוף
סטאטיסטירות גלישה ( אם הותקנו).
37. יש להגביל למשתמשים ותפקידים – גישה לכל משאב קריטי במערכת
38. ביטול הרשאות מיידי ככל הניתן עבור משתמש שעזב את החברה או עבר תפקיד
וכו.
לוגיקה עסקית - Business
Logic
39. יש לדרוש מהמשתמש את הססמה הנוכחית בכל פעם שנדרש שינוי או הוספה של
פונקיונאליות באתר.
40. בתהליך שחזור סיסמה ,אין
לשלוח את הסיסמה במייל או באמצעי אחר – במקום זאת יש לשלוח לינק מוגבל בזמן המכיל
דיאלוג לאיפוס סיסמה.
41. יש להשתמש בשאלות סודיות או אמצעי דומה בתהליך אחזור סיסמה
42. אין לתת שמות קלים לניחוש עבור ספריות ודפים קריטיים באתר (e.g. admin, administration).
43. במעבר חומר מסביבות ה TEST QA וכו לסביבית ה PROD – יש לדאוג שלא יועברו מקורות
לא נחוצים (e.g. test codes, demo applications, backup
files) בנוסף, יש
להסיר הערות מקוד המקור ויש לוודא כי נשמרת שלמות ואמינות החומר בזמן המעבר.
44. יש לבדוק מפעם לפעם כי דפים קריטיים
במערכת ADMIN וכו לא נסרקים
ע"י מנועי חיפוש GOOGLE BING וכו.
אימות נתונים – data
validation
45. יש לאמת את כל הקלטים מהמשתמשים בצד השרת,יש להעדיף שימוש ב רשימות
לבנות מאשר ברשימות שחורות White-lists should be preferred
for validation instead of black-lists.יש לקדד כל קלט לקידוד נפוץ לפני ביצוע
הבדיקות
46.
כל קלט
המשתמש המשתמש כחלק מפקודה ( שאילתא ל DB וכו) יופעל רק לאחר ביצוע בדיקות escaped and
validated
47.
שימוש
בטכנולוגיות למניעת התקפת SQL INJECTION -Prepared statement, parameterized query, bind variables and whitelist
data
48. כל קלט מהשמשתמש יקודד ויבדקו אורכו ותכנו לפני שיוצג בחזרה על מסך
המשתמש.
49.
כל קלט משתמש המשמש
לחישובים מטמטיים יבדק לערכי מינימום ומקסימום
50. כל קלט משתמש המשתמש לגישה לקבצים יעבור בדיקה וסניטציה
51. בתהליך העלאת קובץ file upload – יבדקו – שם,גודל ,סוג , ותוכן
הקובץ לפני בתחילת התהליך
52. קלט משתמש המשמש לביצוע הפניה במערכת REDIRECT – יבדק באמצעות white list וזאת כל מנת למנוע התקפות פישינג prevent
phishing attacks (open redirect problem).
53. כל קלט משתמש עבור שאילתות LDAP – יעבור בדיקות
54. כל קלט משתמש עבור xpath - יעבור בדיקות
55. ניקוי CR/LF characters מקלט המשתמש למניעת CRLF injection attack
56. יש ליישם פתרונות עבור התקפות frame busting and
clickjacking
57. יש לבצע בדיקת חדירות לפני עליית האתר החדש לאוויר
מניעת שירות – DOS ATTACKS
58. יש ליישם אמצעים לוידוא גורם אנושי ( CAPTCH וכו) בטפסים FORMS באתר.
59. יש ליישם מנגנון TIMEOUT עבור חיפשים באתר ולמנוע סוגי חיפוש מעמיסים כגון חיפוש * וכו
שירותי WEB – WEB SERVICES
60. יש ליישם אוטנטיקציה עבור גישות ל WS בטכנולוגיות SOAP,
Restful, XML-RPC וכו
61. יש לבצע INPUT VALIDATION וטיפול בערכי מינימום מקסימות של ערכים למניעת מתקפות (e.g. external entity, a
billion laughs, XML bomb, etc
