היי,

 

להלן הנחיות א"מ :

 

האתר מאושר לעלות לאוויר בהתאם לתיקון הממצאים עד לאתריך 17.1.2016.

 

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

·         המערכת חושפת שגיאות שאינן כלליות (מה שמנע את הקשחת השגיאות בשרת ומצריך החרגה ב-WAF), לדוגמה בעת תהליך אימות המשתמש, ברגע ששם המשתמש או הסיסמה אינם תקינים, חוזרת שגיאת קוד 400, ופירוט מלא של השגיאה לדוגמה:

{"error":"Bad Request","error_description":"{\"Status\":2,\"IsfirstLogin\":false,\"CaptchaNeaded\":false,\"GoToRoute\":12,\"IsUserLoked\":false,\"CaptchaPassed\":false,\"NayadNotFound\":false,\"NayadForGUI\":null,\"NewPasswordNeeded\":false,\"SendSMSFailed\":false,\"Failure\":false,\"ErrorOrTimeout\":false,\"Locked\":false,\"IsRegulationsNeeded\":false,\"IsShamapNeeded\":false}"}

·          מעבר לכך נראה כי שינוי השגיאה החוזרת בצד המשתמש משפיעה על התנהגות הקליינט, לדוגמא על יד שינוי פרמטר (true\false) ניתן לעקוף את מנגנון ה-Captcha

 

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

 

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

 

פעולות שיש לבצע:

·         אנו צריכים סביבת בדיקות מקבילה לסביבת הייצור (שרת היושב בממשל זמין) בכדי לתחקר את האפליקציה מעבר

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

·         שינוי מנגנון הנעילה כך שיתבסס על חסימת המשתמשים על בסיס המשתמש עצמו ולא על בסיס IP בלבד

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

ניתן לדווח על הנעילה ישירות לדואר האלקטרוני של המשתמש או בהודעת הכישלון בהתחברות הרגילה ("שם משתמש וסיסמא לא נכונים, יתכן והמשתמש ננעל אם ניסית מספר רב של פעמים")

בברכה,