הקדמה לחלק שלישי



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





הרשאות ל-assembly בודד



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

נסתכל על assembly כלשהוא שכתבנו בעצמנו. נניח לצורך הדוגמא שמדובר ב-assembly המכיל קוד לחישובים מתמטים כלשהם שאינו מבצע כתיבה או קריאה לקבצים. היות ואנחנו כתבנו אותו, אנו יודעים שהוא לא מהווה סיכון מבחינה אבטחתית ואין לנו בעייה לתת לו הרשאות של Full Trust. השאלה הנשאלת היא מה אנחנו לא יודעים. ייתכן וקיים באג כלשהוא שתוקף מיומן יכול לנצל כיצד לגשת לקבצי מערכת שאינו מורשה להם. אם אכן ניתן Full Trust, עשינו לאותו תוקף כבר חצי עבודה – כל מה שנותר לו הוא לנצל את הפרצה. מצד שני, אם נסיר את ההרשאות למערכת הקבצים עבור assembly זה לחלוטין, סגרנו את הפרצה לחלוטין.

כבר ראינו בחלק הראשון כיצד ניתן לעשות זאת – ע'י הגדרת מדיניות אבטחה ומתן הוכחות מסויימות ל-assembly נוכל להחליט בדיוק אלו הרשאות ניתנות לו. הבעייה מתחילה כאשר מדובר על מספר רב של assemblies: אם assembly אחד דורש הרשאות כתיבה, אחר דורש הרשאות גישה למשתני סביבה ושלישי דורש הרשאות לגישה לרשת לדוגמא, הרי שנדרשת עבודה רבה כדי להגדיר את מדיניות האבטחה ולייצר את ההוכחות. כמו כן, עלינו לזכור שמטרת מדיניות האבטחה וההוכחות היא לזהות את מקור ה-assembly ולא את מטרתו.

לצורך כך מאפשר מנגנון ה-CAS לכל assembly לבצע פעולה בשם בקשת הרשאות (permission request) על מנת להצהיר מהי קבוצת ההרשאות שהוא עצמו צריך כדי לרוץ. בקשת ההרשאות מתבצעת ע'י שימוש ב-attributes ברמת ה-assembly כך שהמידע נשמר בתוך קובץ ה-assembly עצמו וניתן לקרוא אותו באופן ישיר. כאשר ה-CLR טוען assembly כלשהוא הוא בודק האם קיימת ל-assembly זה בקשת הרשאות ובמידה שכן, הוא מצמצם עוד יותר את ההרשאות שמאפשרת מדיניות האבטחה. יש לשים לב שאם אין בקשת הרשאות מוצהרת, ה-CLR יתייחס ל-assembly כאילו ביקש FullTrust ולכן יקבל את מלוא ההרשאות המוגדרות במדיניות האבטחה.





סוגי בקשות



נראה כעת את סוגי בקשת ההרשאות הקיימים.





הרשאות מינימליות



אלו הן ההרשאות הנדרשות על מנת שה-assembly יוכל לעבוד. במידה והרשאה כזו אינה מאושרת ע'י מדיניות האבטחה, ה-CLR יסרב לטעון את ה-assembly ונקבל PolicyException. כמו כן, ה-assembly לא יקבל הרשאות שאינן מוגדרות למרות שמדיניות האבטחה מאפשרת אותן. בצורה כזו ניתן להמנע מבעיות אבטחה הנובעות מבאגים ופרצות. לדוגמא:

קוד:

[assembly:FileIOPermissionAttribute(SecurityAction.  RequestMinimum, 

  Read=”C:\\Temp”]

  

על מנת שה-assembly המכיל את השורה הנ'ל יטען, על מדיניות האבטחה להקצות לו הרשאה לקריאה מהספרייה C:\Temp. אם אין הרשאות כאלה, נקבל exception.





הרשאות אופציונאליות



אלו הן הרשאות ש-assembly כלשהוא יוכל לקבל במידה ומדיניות האבטחה מאפשרת אותן. אם לא, ה-assembly עדיין יכול לרוץ בלעדיהן. לדוגמא:

קוד:

 

  [assembly:FileIOPermissionAttribute(SecurityAction.  RequestOptional,  

  Write=”C:\\Temp”]

   

במקרה זה, אם מדיניות האבטחה מאפשרת ה-assembly יקבל הרשאת כתיבה לספריית C:\Temp. אם לא, ה-assembly עדיין יטען וירוץ אך יקבל SecurityException בכל פעם שינסה לכתוב לספרייה.





הרשאות אסורות



אלו הן הרשאות שה-assembly לא יקבל לעולם, למרות שמדיניות האבטחה מאפשרת אותן. אם נחזור רגע לדוגמא הראשונה – assembly שכתבנו שמבצע חישובים ומקבל Full Trust ממדיניות האבטחה – אזי נוכל לשלול את הרשאות הכתיבה בצורה הבאה:

קוד:

 

  [assembly:FileIOPermissionAttribute(SecurityAction.  RequestRefused]

   

כך אין סיכוי שפרצה כלשהיא בקוד תשמש לקריאה או כתיבה מהדיסק.





שימוש מושכל ב-CAS



להלן מספר עצות לשימוש ב-CAS:

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

סיכום



בסדרת מאמרים זו סקרנו בקצרה את היכולות השונות הקיימות במנגנון האבטחה של ה-.Net Framework ראינו כיצד ניתן להשתמש בחלקים השונים של ה-Code Access Security על מנת לוודא שהקוד שלנו עושה אך ורק את מה שאנו רוצים שהוא יעשה ושום דבר מעבר. בנוסף, ראינו גם כיצד ניתן למזער את סיכוייו של תוקף פוטנציאלי לעשות שימוש לרעה בפרצות.

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

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

תשובה לשאלות:
1. באיזה מצב יש פרצת אבטחה? פרצת אבטחה זה כל דבר שתוקף יכול לנצל כדי להתערב בפעולה התקינה של הקוד שלך ו/או לשלוף ממנו מידע רגיש שאינו נגיש באופן ישיר. לדוגמא:
כתבת ASSEMBLY כלשהוא שמבקש מהמשתמש את מספר כרטיס האשראי ושמרת אותו במשתנה ב-CLASS שמוגדר בתור PRIVATE. הקוד עובד, האלגוריתמים ומבני הנתונים כתובים בצורה יעילה והלקוחות מרוצים. אבל עכשיו בא תוקף וקורא ל-ASSEMBLY שלך מתוך ASSEMBLY שלו שרץ ב-FULL TRUST. יש לו הרשאות לעבודה עם REFLECTION, ולכן הוא פשוט יכול להסתכל על כל השדות ב-CLASS שלך ולשלוף בקלות את מספר כרטיס האשראי. וזה באג בקוד שלך, למרות שהוא רץ ועושה את העבודה. זה גם אומר בהכרח שכל הלקוחות שלך שמריצים את הקוד הזה חשופים להתקפה. ולכן לא שומרים מידע רגיש בזיכרון לאורך זמן, אלא שולפים אותו ע'פ דרישה ממקור מאובטח ומנקים אותו מהזיכרון כמה שיותר מהר.
2. האם הקובץ מוריד לעצמו את ההרשאות? בפירוש לא. קוד ב-NET. לא יכול לשנות לעצמו הרשאות בשום מקרה (אחרת אין משמעות למערכת האבטחה). ASSEMBLY מסוים יכול להצהיר בפני ה-CLR מה ההרשאות שהוא באמת צריך, ולקבל מה-CLR רק את ההרשאות האלה. כלומר, אם מדיניות האבטחה מאפשרת ל-ASSEMBLY מסויים לקבל הרשאות Y, X ו-Z אבל ה-ASSEMBLY צריך רק את X הוא יכול להצהיר על כך בפני ה-CLR ומראש לא לקבל את Y ו-Z. בכל מקרה, הוא לא מחליט בעצמו - הוא רק מספק ל-CLR מידע להחלטה. חשוב להבין שזה METADATA שנשמר עם ה-ASSEMBLY עצמו - גם אתה יכול לחפש את ה-ATTRIBUTES האלה כמו כל מידע אחר על ה-ASSEMBLY.
מה מרוויחים מזה? אני אסביר עם עוד דוגמא: הקוד שלך צריך רק את הרשאה X. יש עוד עשרות שונות של הרשאות. זה יהיה מאוד לא נוח ללכת על כל מתודה בקוד שלך ולשלול עבורה באופן ישיר כל אחת מעשרות ההרשאות האחרות (ראה חלק שני של המאמר על שלילת הרשאות). אם אמרת מראש שה-ASSEMBLY שלך צריך רק את X לא תקבל את ההרשאות האחרות בכלל ולכן לא תצטרך לשלול אותן. כדי להבין למה בכלל כדאי לרוץ עם מינימום הרשאות אני ממליץ לך לקרוא כאן:

PRINCIPLE OF LEAST PRIVILEGE

מקווה שעזרתי.

הבנתי אחשיו. תודה רבה על ההסבר הברור!.
אבל אחשיו צצה לי שאלה אחרת, אם ה-ASSEMBLY שמבקש הרשאות מסוימות ממנגנון X, מה מונע מהתוקף לשנות, להרוס את מנגנון CRL? הרי הוא אחראי לזה לא?

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

אוקי!. תודה שוב!.