אבטחה WCF

Question

בס"ד

שלום

אני בונה WCF שאמור לשמור נתונים מאובטחים ,אין לי נסיון קודם באבטחה ,

מה הם הדברים העיקריים שנדרשים עבור אבטחה?

כרגע אני משתמשת רק בפרוטוקול של soap1.1 soap1.2

האם rest נקרא פחות מאובטח?

בברכה

י.שולמן

Answer 1

בס"ד

את הWCF אני שמה בשרת יעודי מאובטח וכן SSL ,השאלה היא מה עוד עלי לעשות בWCF עצמו?

י.שולמן

Answer 2

אין קשר ישיר בין REST לבין אבטחה

REST היא ארכיטקטורה של אפליקציות שעובדות בשיטת request->response ז"א אחד הצדדים שולח בקשה כל שהיא לצד השני והצד השני מבצע מה שהוא צריך ומחזיר תגובה לצד הראשון (יש צד יוזם וצד מגיב).

אתרי אינטרנט רגילים הם אפליקציות REST אידאליות מכיוון שהדפדפן שולח בקשה ל URL והשרת מגיב ושולח את הקוד של ה HTML+JS+CSS וכו חזרה אל הדפדפן. גם עבודה עם WCF בעקרון היא כבר מהיסוד שלה עבודה בשיטת REST (לא בהכרח כמו שגם אתר אינטרנט יכול לעבוד בשיטות כמו שמירה על קשר דו כיווני אבל זה היסוד והדרך הנפוצה יותר של כל שירות).

* ניתן לטעון תיאורטית שעבודה בשיטת לקוח-שרת (REST) היא שיטה יותר בעייתית מפני שיש מספר רב של פניות לשרת בניגוד לעבודה בשיטה דו-כיוונית בה מבוצעת ההתחברות פעם אחת בלבד. זה לא מדוייק וכאמור זה לא קשר ישיר מפני שניתן בניגוד לכך לטעון שבשיטה של קשר דו-כיווני מרגע שמישהו הצליח להאזין למה שקורה הרי שהכל פתוח לו בעוד בשיטת לקוח-שרת יש לבצע בקשה בכל פעם מחדש ולכן ניתן יותר לתפוס מצבים בעייתייים בזמן ולחסום המשך שלהם. זה לא ממש מדוייק ורק אני מציג את זה כבסיס לרעיון.

http://he.wikipedia.org/wiki/REST

עד כאן על המילה REST בה השתמשת :-) ועתה לנושא אבטחה:

כאשר כל הפעולות מבוצעות באפליקציה שאין לה קשר חיצוני הרי שאין משמעות לאבטחה מכיוון שאין מי שיכול להגיע אליה. לכן האבטחה הכי טובה היא פשוט לא לפתוח את המחשב או לא לחבר אותו לשום רשת חיצונית. כמובן שזה לא מעשי :-)

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

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

* כמה שפחות העברת אינפורמציה סודית כך יותר טוב (למשל העברה של סמאות ונתונים של משתמש היא אינפורמציה סודית). כמה שיותר עבודה פנימית ורק העברת מה שחייבים להחזיר.

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

* ניתן לעבוד עם VPN או כל צורת אבטחה אחרת הקשורה להבלת הגישה אל השירות...

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

Programming WCF Security

WCF Security Checklist

---

Answer 3

בס"ד

קודם כל תודה על התשובה המהירה והיעילה

הלינקים שקיבלתי הועילו לי בהבנה יותר מעמיקה של נושא אבטחה בWCF

יש לי עדיין מס שאלות

בקצרה על הפרוייקט

אני בונה WCF  שאמור לשמור מספרי אשראי ,כביכול מתווך בין לקוחות שרוצים לסלוק לבין שב"א

שלשם אני מעבירה את העיסקאות ,אמור לעמוד בתקן PCI-DSS.

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

האתר עצמו יהיה על שרת מאובטח+SSL  ,השאלה היא מה הם הדברים העיקריים שעלי ליישם באבטחה של WCF ?

או שאולי השרת המאובטח מספק???

1.WCF אמור לתקשר עם כל אתר ,גם עם ACCESS ,השאלה איזה פרוטוקולים עלי לאפשר שיתאימו לכולם ,וגם מבחינת אבטחה יהיו יעילים,שאלתי על  rest ' כי ראיתי שהWC  של שבא שאליו אני מתממשקת עובד על soap1.1/soap1.2  בלבד ,חשבתי שאולי זה עניין של אבטחה ,או אולי זה הצורה המקובלת  בweb service asmx?כרגע גם אפשרתי soap1.1/1.2 וזה עובד גם מaccess

,

Answer 4

כמה נקודות בקצרה כרגע:

1. הדרך הכי קלה לעבור תקינה של PCI DSS מנסיוני זה פשוט לבצע את האבטחה הבסיסית שכל מפתח צריך לדעת ואז לפנות לחברה שנותנת את התעודה (יש הרבה חברות שמספקות את התעודה ואם לא מכירים בדרך כלל חברת האשראי תפנה אתכם למישהו שיש להם אנטרס/קשר איתו... זה לא ממש בעיה בעיני ואפילו ייתרון לפעמים לגשת למי שהם מפנים אליו).

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

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

3. WCF יכול לתקשר בכל פרוטוקול בעקרון (הניגוד ל WEB SERVICE). תבדקי אם את עובדת באמת עם WCF או WEB SERVICE הישן יותר. כמובן שיכול להיות שהצד שפיתח את ה WCF חסם פרוטוקול אחר כמו HTTPS למרות שאני מבין למה לבצע את זה, בכל מקרה אין לכך חשיבות. כל עוד את מצליחה לתקשר איתו הרי מה טוב. נשאר רק לאבטח את הקשר הזה...

4. לא טוב שהתבקשת לשמור מספרי כרטיס מפני שלידיעתי זה לא חוקי וכשתרצי לאשר את התעודה של ה PCI DSS זו אחת השאלות שהם ישאלו אותך. תשובה שאת שומרת את המספר יוביל לפסילה שלך בכל חברות האשראי לנסיוני (אלא אם תספקו להם הסבר טוב - הם יאפשרו לך לספק להם תירוץ טוב והסברים בעקרון לאחר שתציגו להם שעברתם את הסריקה של ה PCI_DSS). מבחינתם את אמורה לשמור רק את 4 הספרות האחרונות (חלק מהמספר) בעקרון.

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

יש גם הגדרות ברמת השרת/ה IIS ועוד למשל שיש לבצע כמו protocols, ciphers, hashes and key exchange algorithms. למשל עבודה עם ciphers נמוך יותר מ TLS 1.1 לא יעביר אותך את הסריקה....

הקישורים הבאים יוכלו לעזור לך בשלבים הבאים:

• Qualys SSL site analyzer
• SSLScan open source scanning tool
• CryptoNark Perl based PCI compliance checker

הערה חשובה: חברות הסריקה (סריקה ולא סליקה) מניסיוני מבצעות עבודה על הפנים במערכות מורכבות ומיוחדות. זה חלק מהסיבה שיש עדיפות לפנות לחברה שחברת האשראי שלחה אליה. הסריקות נעשות במנועים מובנים מראש והם עושים טעויות. טעות נפוצה לדוגמה היא שפוסלים אתר שיש בו טופס אם ה action לא מכיל כתובת בפרוטוקול HTTPS. היתה לי מערכת מאובטחת למשל שביצעה את השליחה בלי בכלל לשלוח את הטופס (לא היה SUBMIT בכלל). השליחה רק לקחה מהטופס את הנתונים והיא בוצעה בצורה מאובטחת באג'קס תוך שימוש ב JS. האתר היה מפותח ב WEB FORM לצערי ולכן נוצר טופס של ה asp.net. למרות שהוא לא היה קשור בכלום לשליחה של הנתונים האתר נפסל בסריקה והם הצביעו על כך. כמובן שהתיקון לקח כמה שניות אבל חבל. לא נעשתה שום בדיקה ידנית ולא עניין אותם הסברים... אם היו בודקים ב fiddler או בכל כלי פיתוח (אפילו זה של הדפדפן) היו רואים שכל השליחה נעשית בצורה מאובטח ב HTTPS. הם עובדים עם המנוע שלהם והתוצאות שלו הם מה שמעניין אותם. במקרה אחר הם העבירו/אישרו מערכת שלקח לי כמה שניות (בגלל שהקוד היה נגיש לי) למצוא פירצה פשוטה. עוד מקרה שהיה זה שהם לא מצאו את אחד הטפסים במערכת מפני שלא היו לו קישורים והמנוע שלהם פשוט דילג על הבדיקה שלו. במקרה זה היה טופס שבאמת לא היה מאובטח ואיבטחתי אותו כמה ימים טובים אחרי שהמערכת כבר היתה עם תעודה פעילה. יש עוד דוגמאות שנובעות מכך שמדובר במנועים אוטומתיים שלא מבצעים חשיבה אנושית....

---

Answer 5

בס"ד

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

 רק שהוא לא נותן הנחיה בעניין של פיתוח מאובטח,WCF ,ואין לי ניסיון בזה 

שאלה נוספת שיש לי:

אני משתמשת בentity frame work ,האם זה בסדר מבחינת אבטחה ,

המודל פתוח לאורך כל הזמן שהWCF פעיל ,האם זה בסדר?

בתודה מראש

Answer 6

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

* אנא עברי על מה שרשום בתמונה שחתימה שלי :-)

2. לגבי השאלה החדשה: אין קשר בין מה שקורה בצד השרת ובין אבטחה של הקשר של השרת ללקוח. את יכולה לעבוד בכל ORM שאת רוצה וכאמור זה לא קשור ללקוח או לקשר ללקוח ולכן אין בכך שום קשר לשרת. תמיד מומלץ לנסות להבין מה קורה מאחורי הקלעים ולחשוב מה הקשר שלו לבעיה (כמו עניין אבטחה בין לקוח לשרת)

יש עניין אחר והוא אבטחה בקשר בין השרתים אבל זה כאמור עניין אחר כבר. למשל אבטחה של קשר בין השרת IIS לבין השרת SQL ואם הם על 2 מחשבים שונים הרי שזה עוד נושא שיש לקחת בחשבון כשדנים על אבטחה וצריך לאבטח גם את הקשר הזה.

בעקרון זו עוד נקודה בעייתית שמבחינתך היא ייתרון דווקא. מנועי הבדיקה של PCI DSS של חברות הסליקה לא בודקות את הנושא הזה בכלל מנסיוני, ואינן מודעות לקשר שני או שלישי או רביעי שהתוכנה מייצרת, אלא רק לקשר הראשוני בין הלקוח לשרת (קשר שני אני מתכוון אם הפנייה של הלקוח לשרת A גוררת פנייה של שרת A לשרת B וזה למשל פונה לשרת C בקשר שלישי וכו'). זו בעיה חמורה שתיאורטית חייבים לסגור אותה לפי תקן PCI המלא.

* אני מציע לסגור את השירשור (סימון כל התשובות בדרך) כבר, מפני הוא כולל הרבה שאלות. אישית אני ממליץ תמיד לשים כל שאלה בשרשור חדש מכיוון שככה מי שמחפש תשובה לשאלה מסויימת יכול למצוא אותה ולא צריך לקרוא דברים מיותרים. למשל כל הנושא של PCI DSS הייתי חושב שהוא שווה שירשור חדש ואינו קשור לשאלה המקוריות ישירות. האם EF מפריע לאבטחה או לא, זו שאלה שאינה קשורה ל PCI אלא שאלה כללית עם תשובה קצרה....

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

---

Answer 7

שולמ

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

הבקשה לסגור את השירשור היא לא קשורה לך אלא מתוך מה שניסיתי להבהיר: הפרדה של כל נושא של שאלה לשרשור בנפרד.

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

---