Latest Security News

WEB APPLICATION SECURITY-מתורגם לעברית



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

3.      חסימה ברמת השרת  "דיפוף בתקיות" – directory listing


מידע נוסף
 APACHE

מידע נוסף  IIS 
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 וכו
8.       יש ליישם את כל יכולות האבטחת של סביבת אפליקציה e.g. ASP.NET, PHP, STRUTS וכו
http://msdn.microsoft.com/en-us/library/ff648652.aspx

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" ); 

11.  ביטול מנגנוני הצפנה חלשים בפרטוקול SSL ( SSLv2 וכו) ושימוש במנגנונים חזקים בלבד לצורך תקשורת מוצפנת.
http://www.amixa.com/blog/2010/06/22/disabling-sslv2-support-in-iis/
http://www.linux4beginners.info/node/disable-sslv2

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 והן ברמת הלקוח
15.  יש לקודד או להצפין ססמאות ותשובות לשאלות לשחזור סיסמה ברמת ה DB ( SALTED HASH)
http://crackstation.net/hashing-security.htm

16.  שימוש ב HTTPS SSL עבור כל תעבורת מידע קריטי כגון ססמאות, כרטיסי אשראי ,מידע אישי וכו
17.  כל בדיקות ההזדהות וההרשאות יתבצעו בצד השרת SERVER SIDE
18.  ביצירת ערכי HASH עבור ססמאות יש להסיף ערך SALT יחודי עבור כל ערך HASH
http://crackstation.net/hashing-security.htm
19.  יש לכפות על המשתמשים  שינוי הסיסמה הראשונית שקיבלו באמצעים כגון מייל או אס אם אס.
20.  כל פעילות קריטית במערכת תשמר ביומן ((LOG  הן ברמת השרת והן ברמת האפליקציה.
21.  יש לשמור לוג של כל הזדהות טובה וכל הזדהות שגויה (successful and unsuccessful login).
22.  יש להציג הודעה ג'נרית עבור כשלון הזדהות:  Username and/or Password is wrong

Session management

23.  יש להשתמש במחוללי מספרים רדנומאליים מורשים ומאובטחים עבור כל מזהה חד עדכי המערכת (e.g. session identifiers, token etc.)
http://msdn.microsoft.com/en-us/library/ms178581.aspx
http://www.php.net/manual/en/book.session.php
24.  יש להגדיר זמן ניתוק עבור כל חיבור לא פעיל למערכת (inactivity timeout(
http://www.php.net/manual/en/session.configuration.php#ini.session.cookie-lifetime
http://www.schnieds.com/2009/07/aspnet-session-expiration-redirect.html

25.  יש לייצר מזהה חד ערכי חדש ( session id ) עבור כל כניסה למערכת +כניסה מחדש וכן לבטל את המזהה לאחר ביצוע יציאה מהמערכת.
26.   במסכים קריטיים – יש ליישם פתרונות CAPTCHA או TOKENS למניעת CSRF  ו DDOS .
https://developers.google.com/recaptcha/
27.  עוגיות ( COOKIES) המשמשות להחזקת SESSION ID – יאובטחו ויוגבלו לשימוש באותו אתרDOMIAN  בלבד.
28.  החלת מאפיין  httponly  עבור COOKIES בתקשורת HTTP והחלת מאפיין secure  על עוגיות בתקשורת HTTPS ( למניעת גישת javascript לעוגיות וגנבתם בהתקפת XSS).
http://thinkvitamin.com/code/how-to-create-totally-secure-cookies/
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