איך גוגל ונטפליקס יודעות מי אתם: הכל על אימות זהות והרשאות גישה

העולם של אימות זהות (Authentication) והרשאות גישה (Authorization) הוא אחד מהתחומים הפחות ברורים בתחום פיתוח התוכנה. מתי משתמשים בכל אחד, מה היתרונות והחסרונות ומהן והטעויות הנפוצות בהטמעה שלהם?

מקור: Unsplash

מאת אליעד מועלם

אחד התחומים הפחות סטנדרטיים וברורים בתחום פיתוח התוכנה הוא עולם אימות זהות (Authentication) והרשאות גישה (Authorization). היעדר סטנדרטיזציה לצד ריבוי ממשקים בין מערכות ובין משתמשים למערכות הופך את משימת הגדרות אימות הזהות והרשאות הגישה הקריטית למניעת חדירה למערכות. למפתחי שירותים אינטרנטיים (אתרים, אפליקציות, APIs) אין סטנדרט שמכתיב איך לנהל את החיבור לשירות שלהם, כל מפתח יכול לממש את גישתו בדרך שבה הוא בוחר ולכן יכולות להיווצר נקודות תורפה רבות שתוקפים יכולים לנצל, לדוגמא: גישה למשאבים של משתמש אחר, הרצת פעולות בשם משתמש אחר, גניבת פרטים אישיים, גישה למשאב שאמור להיות מאובטח אבל בעצם נגיש לכלל וכו׳. בעיות אלה נוצרות במקרים רבים כתוצאה משימוש לא נכון בשיטות אימות זהות והרשאות גישה.

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

Authorization – Cookies and Tokens

ה-cookie שמוכר לכולם הוא אובייקט שהשירות האינטרנטי מאחסן ושולח למי שמבקר אותו, לאחר השליחה הראשונית שלו הדפדפן ישלח אותו עם כל בקשה לאותו השירות האינטרנטי וכך ישמר מידע על ה-session של האדם הספציפי. cookies יכולים גם לספק הרשאות גישה – לאחר שאדם מתחבר יתווסף ל-cookie שלו מידע נוסף לגבי הזהות שלו וכך השירות האינטרנטי ידע לאן מותר לאותו המשתמש לגשת. Token הוא גם אובייקט שהשירות האינטרנטי שולח אבל הוא לא צריך לאחסן אותו אצלו בניגוד ל-cookie, תהליך האימות של ה-token נעשה אך ורק בעזרת המידע שקיים ב-token, בעזרת החתימה שקיימת ב-token יכול השרת לוודא שלא זייפו אותו, בנוסף שימוש ב-token חוסך לשרת המון גישות ל-database, כל המידע שהשרת צריך בשביל לוודא את ה-token נמצא בתוכו בנוסף לפרטים על המשתמש (תלוי במימוש). סוגי token נפוצים: Bearer, MAC.

גם cookies וגם tokens נמצאים בשימוש נרחב, אין כמעט שירות אינטרנטי שלא משתמש באחד מהם או בשניהם בשביל החיבור של המשתמש. כאשר לא מטמיעים אותם בצורה נכונה, יש סכנה לניצול לרעה על ידי תוקף. לדוגמה ב-cookies יכולים להיות פרמטרים שמקשרים את החיבור שלנו באותו האתר למשתמש שלנו ואם נשנה את אותו הפרמטר נוכל לקפוץ לחשבון של משתמש אחר, ב-tokens רשום המנגנון שאיתו מאמתים את אותו ה-token, שינוי של המנגנון לאחד שהוא חלש יותר או מחיקה שלו לגמרי יכולים לגרום לווידוא לא תקין של אותו ה-token על ידי השרת. גם token וגם cookie פגיעים לגניבה, כלומר אם מישהו מסניף את התעבורה של משתמש מסוים והיא לא מוצפנת (https) הוא יכול לגנוב אותם ולהשתמש בהם בשביל להתחבר לאתר בתור אותו המשתמש.

Bearer Token

סוג של token שנשלח לאחר התאמתות לשרת, ה-token צריך להיות רצף מילים מוצפן שרק השרת יכול לפענח או לאמת. לדוגמה מחרוזת שמוצפנת עם המפתח הפרטי של השרת והשרת מוודא עם המפתח הפומבי שלו, שימו לב שכל אחד יכול לראות את התוכן של ה-token בעזרת שימוש במפתח הפומבי של השרת, אבל אף אחד לא יוכל לשנות  את התוכן שלו. דוגמה נוספת היא שימוש ב-JWT (Json Web Token) המכיל מידע על אותו המשתמש בפורמט Json והוא אחד ה-token-ים הכי נפוצים כיום.

Message Authentication Code

עוד סוג של token שפותר את בעיית הגניבה שדובר עליה מקודם, בנוסף הוא מוודא שלא שינו את המידע שנשלח לשרת. השימוש MAC הוא בדרך כלל כאשר לא ניתן/ או שאין רצון להטמיע תקשורת מוצפנת (https). בשביל להשתמש ב-MAC יש צורך בהעברת סוד משותף בין הצדדים ו-id שמקושר לאותו הסוד, לאחר מכן כל בקשה שהמשתמש שולח מכילה את ה-id וה-hash (שנוצר מהבקשה, הסוד, התאריך ועוד פרמטרים) שאותו השרת מוודא, כיוון שהסוד המשותף לעולם לא נשלח עם הבקשות אי אפשר לגנוב אותו. באופן זה ניתן לפתור בעיות גניבה ומתקפות מסוימות נגד cookies ו-tokens. גם אם גורם זדוני עולה על התעבורה של המשתמש הוא לא יוכל להזדהות כאותו משתמש או לבצע פעולות בשמו.

Single Sign On

SSO הוא קונספט אימות הזהות הכי נפוץ כיום. למעשה מדובר בשימוש גורם צד שלישי (Identity Provider) כגון Google, Facebook, Apple וכו׳ בשביל להזדהות אל מול שירות אינטרנטי מסוים. היתרון המרכזי בהתחברות זו הוא שאין צורך ליצור חשבון משתמש (לזכור סיסמאות) בכל אתר שנתחבר בו בצורה זו. נצטרך רק לזכור סיסמה אחת והיא תהיה לאתר צד שלישי שמאמת את הזהות שלנו ודרכו נתחבר לכל שירות אחר שנרצה. החיסרון (היחסית זניח) הוא התלות באותו גורם צד שלישי, כלומר אם Google לא יהיו זמינים אז לא נוכל להתחבר לאותו השירות האינטרנטי שתלוי בהם. פרוטוקולים נפוצים: SAML, OpenID(OAuth)

OAuth

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

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

OAuth גם מספק SSO על גבי הפרוטוקול (Open  ID) אבל הוא איננו מספק הרשאות גישה אל מול אותה האפליקציה, לדוגמה כאשר אני מתחבר לשירות אינטרנטי מסוים דרך Google, OAuth דואג לתהליך אימות הזהות שלי אל מול השירות האינטרנטי, אבל לאחר האימות, המשך התקשורת שלי עם השירות האינטרנטי נעשית לגמרי לפי המפתח של אותו השירות, הוא יכול להשתמש ב- Cookies, Token או בכל אפשרות אחרת בשביל לנהל את המשך הגישה של המשתמש.

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

Authorization Code

הקונספט המרכזי של OAuth (לא נוכל לעבור על כולם) שנמצא בשימוש לגישות של אפליקציה לאפליקציה – התקן הזה נותן לאפליקציה זהות כמו של בן אדם – האפליקציה הופכת להיות ישות בפני עצמה. פרוטוקול OAuth משתמש ב-Client ID ו-Client Secret עבור זיהוי של קוד צד שרת, השרת משתמש בשני הערכים האלה (שאפשר להקביל אותם לשם משתמש וסיסמה בהתאמה) בתהליך קבלת הרשאות בפרוטוקול OAuth.

ניקח לדוגמה אפליקציה שעושה סטטיסטיקות על חשבון twitter של משתמש. כותב האפליקציה יצטרך קודם לגשת ל-twitter ולקבל מהם Client ID & Secret שהם הנפיקו במיוחד לאפליקציה שלו, לאחר מכן כאשר משתמש רוצה להשתמש באפליקציה הזו הוא יצטרך לאשר לה לגשת לחשבון ה-twitter שלו עם התהליך הזה:

המשתמש ניגש לאתר ולוחץ על כפתור שמאשר גישה לחשבון שלו
המשתמש מועבר לאתר של בעל השירות (twitter בדוגמה שלנו), עם רשימה של הרשאות שהאפליקציה מבקשת
בעל השירות שואל את המשתמש אם הוא מאשר להביא לאפליקציה הנ״ל את אותן הרשאות לחשבון שלו
לאחר שהמשתמש מאשר הוא מועבר חזרה לאפליקציה עם קוד זמני שבעל השירות יצר
האפליקציה לוקחת את הקוד הזמני וביחד עם ה-Client ID & Secret היא ניגשת בעצמה אל בעל השירות
בעל השירות מחזיר לאפליקציה token עם תוקף מסוים והרשאות מסוימות בחשבון של אותו המשתמש

API Key

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

אין סטנדרט ספציפי לגבי השימוש ב-API Key, הוא יכול להופיע בכל מיני מקומות בבקשה (cookie, header, query parameter) וגם בשמות שונים (api_key, key, subscription-key). טעות נפוצה היא להטמיע API Key באפליקציות שמופצות בפומבי ובכך ה-API Key, שאמור להיות סוד שמור אך ורק למי שקיבל אותו, ידוע לכל משתמש שמוריד את האפליקציה ועלול להיות משומש לרעה על ידי תוקפים.

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

הכותב הוא חוקר אבטחת מידע בחברת הסייבר Noname Security

 

כתב אורח

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

הגב

8 תגובות על "איך גוגל ונטפליקס יודעות מי אתם: הכל על אימות זהות והרשאות גישה"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
יובל
Guest

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

מישהו שמבין עניין
Guest
מישהו שמבין עניין

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

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

חבל.

יובל
Guest

לא פירטתי בגלל שזה יהיה לכתוב כתבה בעצמי. באמת מתנצל :)
כמה נקודות לדוגמה:
ApiKey זה לא סודי. SSO זה לא שיטה לאימות זהות. יש שם בילבול בשמות הפרוטוקולים ובשימושים. בנוסף MAC או HMAC זה לא token , זה נועד לאמת שלא שינו את ההודעה בדרך אבל עדיין לא מזהה את המשתמש. וחשוף ל replay attack אם לא מועבר עם nonce וזמן.
יש עוד שאני לא זוכר כרגע ואין לי כח לקרוא את הכל שוב. אבל כמעט בכל פיסקה היתה טעות או חוסר דיוק. ולא באתי לפתוח על זה דיון.
ממליץ לך לקרוא על הנושאים כל אחד לגופו.

שירן
Guest

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

NP>P
Guest

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

ג\'וג\'ו צנעני
Guest

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

גל לוי
Member

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

miklas
Guest

I really enjoyed, I would like to know more about this article because it is very good, keep it up. Thanks for sharing.
girls games

wpDiscuz

תגיות לכתבה: