פודקאסט מספר 446 של רברס עם פלטפורמה - אורי ורן מארחים בסוף אוגוסט את אליעד מחברת noname לשיחה על APIs ועל איך לאבטח APIs ב-Web - ולא רק ב-Web.
- (אליעד) לא רק ב-Web - גם בין אפליקציות, השימוש ב-APIs ניהיה נרחב מאוד בזמן האחרון.
(רן) מעולה - אז לפני שנדבר על APIs, נכיר קצת את אליעד -
- (אליעד) אז אני אליעד, כמו שאמרתם - אני בן 26, מתל אביב.
- עקרונית, רוב השנים עבדתי בתחום ה-IR - שזה Incident Response
- שם’ בעצם - הגעת לאירוע, חקרת אותו
- בדקת מה התוקף עשה ברשת - מאיפה הוא הגיע, באילו קבצים הוא נגע
- וממש פעלת בכובע של - הייתי אומר “בלש משטרתי” כזה - של עולם האינטרנט . . .
(אורי) אני נתפסתי לרגע ל . . . “רוב החיים עבדתי ב . . .” - טוב - אתה חצי מהגיל שלי . . . .
- (אליעד) רוב החיים שלי . . .
(רן) אני דווקא הלכתי לכיוון שרלוק הולמס . . .
- (אליעד) כן . . . . אז זה בערך בחמש-שש השנים האחרונות, הייתי ב-Incident Response.
- לאחר מכן, רציתי לעשות טיפה שינוי בעבודה - והלכתי יותר לתחום המחקר
- רציתי לחקור משהו שעכשיו מעניין - שעכשיו כולם משתמשים בו
- וראיתי שכל התחום של ה-Cloud ו-APIs וכל הדברים האלה - זה באמת ניהיה הדבר-די-הכי-חם עכשיו: APIs התחילו לתפוס המון מקום עכשיו בחיים שלנו
- בין אפליקציות, בין אפליקציות ל-DB-ים, בין Cleint-ים לשרתים - הכל עכשיו עובר בעזרת API-ים.
- והעולם הזה ניהיה מאוד מעניין - והתחלתי . . .
- ואז נכנסתי לצוות המחקר בחברת noname
- והחברה - המטרה שלה זה לעשות API Security, כשהמוצר נותן לך שלושה דברים:
- אחד זה ויזיביליות (Visibility) על ה-API-ים שלך - איזה API-ים יש לך, מה הסכמות (Scheme) שלהם, איפה יש אות’נטיקציות (Authentications) - כל הדברים האלה.
- שזה עולם די מבולגן - בדר”כ, אם היית מגיע ל-CISO-ים של חברות או דברים כאלה, והיית אומר לו “תגיד, כמה API-ים יש לך?” - הוא לא יודע, הוא לא בטוח בזה.
- “באיזה מהם עוברים כרטיסי אשראי?” או “באילו אות’נטיקציות (Authentications)?” - דברים כאלה - “אני לא יודע” . . . .
- כל העולם הזה מאוד מבולגן, ובעצם מה שהמערכת עושה בהתחלה זה להביא לך ויזיביליות (Visibility) כלשהי על כל ה-API-ים שלך.
- בנוסף לזה . . .
(רן) אנחנו מדברים על APIs שפונים החוצה? - נגיד, בהקשר של כרטיס אשראי לדוגמא - או שאתה גם מדבר על כל מה שקורה “בפנוכו”?
- (אליעד) אז גם “בבפנוכו” - כל שימוש ב-API-ים, גם אם נגיד בשימוש הכי מוכר ורחב שזה מתכנת שבונה איזו אפליקצית-Web כלשהי ואנשים ניגשים אליה דרך הדפדפן או דרך הטלפון שלהם, ואז בעצם יש כל מיני API-ים שמחזירים לך מידע שהאפליקציה מבקשת או שהדפדפן מבקש.
- ואז זה מוצג על המסך, בשביל המשתמש.
- אז זה ה-API-ים הכי מוכרים . . .
(רן) בסדר . . . בכל מקרה, אנחנו מדברים על “Over-the-Network”, נכון? לא מדברים על דברים פנימיים, שקורים בתוך ה-Process?
- (אליעד) אז לא - זה לא API-ים . . . זה Web-APIs, זה API-ים שעוברים בתוך המחשב עצמו.
(אורי) אוקיי, לא בתוך המחשב עצמו - אבל יכול להיות ש . . .זאת אומרת, אני חברה ואני חושף איזושהי אפליקציה, אבל מעבר לאפליקציה או ל-API-ים שאני חושף החוצה, יש לי עוד . . .
(רן) microServices . . .
(אורי) . . . מיליון-ואחת microServices שמדברים ביניהם ב-API-ים - שזה בעצם “החוזה ביניהם”, גם על . . .
- (אליעד) נכון - אז אם עכשיו יש לך איזשהו DB, או שלא משנה מה פתחת - כל מה שמתקשר באמצעות API-ים . . .
- עכשיו גם בין אפליקציות - גם בין אפליקציות אפשר לתקשר בין API-ים, גם האפליקציות וגם הDB-ים, כשאתה מאנדקס (Index) כשאתה מחזיר מידע ועושה כל מיני שליפות - הכל עובר עכשיו דרך API-ים.
- אז זו בדיוק הכוונה - כל סוג של Web-API שעובר
- אבל לא RPC לדוגמא, אם מישהו פה מכיר - Remote Procedure Call - אז זה לא כאלה, אלא API-ים שקשורים ספציפית ל-Web.
- (אליעד) אוקיי, אז זה סיפור טיפה מצחיק, כששמעתי אותו . . .
- עקרונית, כשהם פתחו את החברה - המייסדים - הם ישר רצו לדבר כבר עם משקיעים ולהשיג השקעות ומימונים וכל זה, ואז עוד לא היה להם שם.
- וב-Email-ים שהם שלחו למשקיעים, הם רשמו להם ש-”It’s a noname API Security company ” - מתוך כוונה להגיד שאין לה שם, עדיין.
- והתגובות שהם קיבלו בחזרה היו “וואו! noname - what a great name” . . .
- אז הם אמרו אוקיי . . . אז זה השם.
- [ומה לגבי אינשם וה-API Call הראשון?]
(רן) טוב שלא הכניסו <סוגריים משולשים>, כמו שבדרך כלל עושים - היה מאוד קשה להגות את זה . . .
בסדר, אז תראה - יש לנו לא מעט דברים שאנחנו הולכים לדבר עליהם ולא נוכל לדבר כל עולם ה-Security של ה-APIs, אז בוא נבחר פה כמה דברים.
אולי נתחיל מזה: אני מייצר עכשיו API שפונה החוצה ואני רוצה לאבטח אותו. מה שלל האופציות העומדות בפני? אילו כלים? מה “ה-Cool Guys” עושים היום כדי לאבטח APIs?
- (אליעד) אוקיי, אז דבר ראשון - וזה הדבר הכי חשוב - קודם כל להבין מי הם המשתמשים של ה-API שלי?
- מי צורך אותו ולאילו מטרות הוא נצרך.
- כי יש לך המון המון סוגי אות’נטיקציות (Authentications) ואות’וריזציות (Authorizations) ודברים כאלה - ואתה צריך לדעת בדיוק למי ה-API מכוון -
- אם זה למשתמשים שבדפדפן
- אם זה בין אפליקציות
- אם זה בין האפליקציה ל-DB
- ודברים כאלה.
(רן) אוקיי, אז נניח דפדפן: אני כותב שירות-Backend שמשרת Frontend שנמצא בדפדפן - והוא שלי - שניהם שלי - ואני צריך לאבטח את כל הסיפור הזה.
מה אני עושה?
- (אליעד) דבר ראשון - בסוף, כשאתה בונה איזשהו אתר, אז מתחברים אליך, נניח, עם שם משתמש וסיסמא, ככה מתחברים לאתר שלך
- ואתה מנפיק לבנאדם שהתחבר אליך איזשהו Token - או אפילו מביא לו Cookie - שבעצם איתו הוא ניגש לאתר שלך, בדרך כלל
- ולך שמורות ב-DB, באיזושהי צורה, ההרשאות שלו - וככה אתה מנהל את זה . . .
- (אליעד) אז להיכנס ממש לעומק, אוקיי . . .
- בוא נעשה את ההבדלה בין אות’נטיקציה (Authentication) ואות’וריזציה (Authorizations), כי הרבה מתבלבלים בזה.
- באות’נטיקציה (Authentication) הכוונה היא אימות המשתמש - אימות הזהות של מי שעכשיו בא ומשתמש ב-API הזה.
- ואות’וריזציה (Authorization) זה אומר אילו הרשאות יש לאותו המשתמש - האם הוא יכול לגשת לאותו משאב או לעשות פעולה מסויימת באפליקציה שלי.
- אז בוא נתחיל טיפה מאות’נטיקציות (Authentications) - נראה לי שכבר אמרתי לפני רגע שהכי מוכר זה להביא שם משתמש וסיסמא
- ואז אתה מקבל בחזרה או Token או Cookie
- עוד מעט נדבר טיפה על ההבדל בין Token ל-Cookie - מה השימוש של כל אחד
- ואז איתו אתה ממשיך לגשת לאותו אתר - וככה אתה בעצם החלפת אות’נטיקציה באות’נטיקציה (Authentications)
- החלפת את השם משתמש והסיסמא ב-Token שלך - ואז אותו אתה שולח.
(רן) אוקיי, זה ממש כאילו “תבנה בעצמך” . . . שם משתמש, סיסמא - לכל אתר צריך . . . המשתמש צריך לייצר לכל אתר שם משתמש וסיסמא, ויש פה לא מעט ”חוב טכני” . . . .
- (אליעד) נכון, יש בעיה מאוד גדולה בשם משתמש וסיסמא . . .
- אחת - אם עכשיו אני לקוח של מאה אתרים: יש לי Facebook ו-Google ויש לי המון . . .
- “מיליון אתרים” - ולכל אחד מהם צריך לזכור את הסיסמא
- ויותר מזה - מי מבטיח לי שהסיסמא שלי תיהיה מאובטחת מספיק? מי מבטיח שאין איזה מישהו שיבוא ויכול לקחת לי את הסיסמא
- אם השתמשתי בסיסמא יחסית פשוטה כמו “Apple” או לא יודע מה, אנשים יוכלו פשוט לבוא ולהיכנס לי לחשבון.
- אז גם זה שאתה סומך על המשתמש שלך שיצור לך [עבורו] את הסיסמא ואת הזיהוי לאתר שלך - זה לא מספיק טוב.
- יש כמה דרכים שבהן אפשר להתמודד עם הדבר הזה
- אחת מהן היא Two Factor Authentication (2FA)
- הרעיון הוא שאם מישהו בסופו של דבר גם השיג את שם המתשמש וגם את הסיסמא - התוקף איכשהו השיג אותן - הוא עדיין לא יוכל להתחבר לחשבון, כי עדיין צריכה להישלח הודעת SMS לטלפון של אותו הבנאדם, והוא צריך לאשר את ההתחברות.
- זה כבר מונע ממך להשיג גישה לאותו החשבון.
- היום יש גם פרוטוקולים יותר מתקדמים - אחד מהם זה SSO, שזה Single-Sign-On
- והכוונה פה היא לקונספט לגמרי חדש, שממש שינה את העולם הזה - הוא בעצם אמר שאין יותר שם משתמש וסיסמא לכל אתר
- יש אתר אחד מרכזי שהוא “המנהל זהויות” - אצלו בעצם רשומים כל האנשים
- כולם מתחברים אליו ולכולם יש שם משתמש וסיסמא - ובדרך כלל הוא גם עם Two Factor Authentication אז גם קשה מאוד לגנוב לך את הזהות שלך לשם
- וכל אתר אחר שאתה נכנס אליו בעצם יאמת את הזהות שלך בעזרת אותו אתר-צד-שלישי.
- נגיד, אם Facebook עכשיו הם נותני הזהות ואני רוצה להיכנס לאפליקציה אחרת - אז אתם תראו כפתור של “Sign-in with Facebook” ובעצם יש איזשהו תהליך שבו Facebook תאמת את הזהות שלי - היא תיהיה האימות שלי עבור אותו האתר, ולא שם המשתמש והסיסמא לאותו האתר.
(רן) אז אולי אין SSO Provider אחד - זאת אומרת זה לא רק Facebook, יש בעולם עוד כמה כאלה - אתה יכול לבחור אם זה Facebook או Google או Twitter או LinkedIn או Whatever, אבל יש כמה גדולים - ובגדול כל משתמש בוחר איפה לנהל את הזהויות שלו, וכמובן שלא צריך לבחור פעם אחת אלא אתה יכול לבחור עבור כל אתר מישהו אחר.
אבל מה זה אומר? איך זה עובד מהצד של מי שמיישם את זה? אם אני עכשיו רוצה להכניס SSO לתוך ה-Service שלי - איזה פרוטוקול אני מנהל מול Facebook או מול Google?
- (אליעד) אז בדרך כלל . . . הפרוטוקול שכרגע הוא די-הכי-נפוץ נקרא OAuth
- כעיקרון, OAuth הוא לא למטרת Single-Sign-On, אלא למטרה אחרת שעכשיו טיפה נרחיב עליה -
- דמיין מצב שבו יש לך חשבון ב-Twitter - ובא לך לתת לאיזושהי אפליקציה חיצונית הרשאות ל-Twitter שלך, כי אתה רוצה שהיא תעשה לך כל מיני סטטיסטיקות על החשבון או כל מיני דברים כאלה.
- אז בוא נגיד ככה - “בעולם של פעם” היית צריך להעביר לאפליקציה את שם המשתמש ואת הסיסמא שלך
- היא הייתה מקבלת הרשאות מלאות לחשבון שלך - היא הייתה יכולה לשנות סיסמא, היא הייתה יכולה לעשות הכל . . . לפרסם בשמך, לקרוא לך הודעות פרטיות
- וזה היה דבר רע לעשות . . . .
- (אליעד) אל תעשו את זה . . . לא לתת שם משתמש וסיסמא לאף אפליקציה ולאף אתר ולשום דבר . . .
- אז OAuth . . .
(רן) היינו חייבים להגיד את זה, לא? . . . . שאף אחד לא יחשוב בטעות . . . .
(אורי) לא, אתה יכול לתת למישהו בשביל השירות שלו - אבל אל תיתן לשירות-צד-שלישי . . .
- (אליעד) כן, אל תיתן לשירות-צד-שלישי את ההרשאות שלך . . . .
(רן) אז דרך אגב - גם אם הבנק שלכם מבקש את השם משתמש והסיסמא: חבר’ה, לא . . . . קודם כל, כנראה שזה Scam, ואם זה באמת הבנק - אז תעברו בנק . . . לא עושים את זה.
בסדר, אז אתה אומר ככה - SSO ו-OAuth זו . . . אולי זו לא הייתה הכוונה במקור אבל זו דרך כיום לממש SSO . . .
- (אליעד) אז אני טיפה ארחיב על זה - OAuth באה ופתרה את הקטע הזה של ניהול ההרשאות
- באה ואמרה “אוקיי, אני עכשיו אתן איזשהו Token שיכיל הרשאות ספציפיות לחשבון”
- ואת זה נראה לי שכולם מכירים - שאתם לפעמים נכנסים דרך איזשהו אתר לאתר אחר, ואתם עושים “Sign-in with Google” -
- אז Google פותחת לכם חלון ואומרת לכם שיש אפליקציה - וזה השם של האפליקציה - והיא עכשיו מבקשת הרשאות מסויימות לחשבון שלכם -
- מבקשת לקרוא הודעות, מבקשת לראות את ה- email שלכם ואת הפרופיל שלכם . . .
- ורשום - “היא לא תוכל לפרסם בשמכם דברים”
- וזה בדיוק הרעיון של ניהול הרשאות - יש לך הרשאות ספציפיות לחשבון, שאתה יכול להעביר אותן לאפליקציה ספציפית.
- ואם אנחנו חוזרים לקטע של ה-Single-Sign-On - ל-OAuth נוצרה איזושהי הרחבה, שקוראים לה OpenID Connect (OIDC)
- אמרו “אם כבר יש לנו את כל הדבר הזה של הניהול זהויות, ואני בוטח בצד שלישי שיאמת אותי - אז בואו נעשה כבר Single-Sign-On”
- בואו כבר “נרכב על הפרוטוקול הזה” ונעשה Single-Sign-On.
- אז זה בעצם המימוש הזה.
(רן) בסדר . . . . ו-Once עשיתי Sign-In - אז יש להם את ההרשאות הללו לנצח, או שגם כאן יש איזשהו פרוטוקול של מתי זה פג-תוקף וכו’?
- (אליעד) אז בדרך כלל, הרעיון של Token-ים זה שהם לא יהיו קיימים לנצח
- בדרך כלל היו שמים אותם . . . יכולים להיות Token-ים שנשארים בחיים לזמן של שעה או לזמן של 24 שעות, תלוי באתר שהנפיק אותם.
- וברגע שהוא הנפיק לך את ה-Token, הוא מנפיק איתו גם משהו שנקרא Refresh Token
- שבכל פעם שה-Token הוא פג-תוקף אז אתה יכול לשלוח את ה-Refresh Token ולקבל חדש.
- וככה, כשהתחברתי ל-Facebook פעם אחת, נניח - או דרך Facebook פעם אחת - הם לא יצטרכו לבקש ממני שוב לעשות את זה.
- יש להם את ה-Token והם בכל פעם מחליפים אותו.
- ועוד משהו, ספציפית למנגנון הזה - מה שכל כך טוב בו שזה שאתה גם יכול לעשות Revoke, ספציפית לאפליקציה שאתה רוצה
- אתה לא חייב עכשיו לשנות את השם משתמש ואת הסיסמא שלך בשביל לבטל את החיבורים של אנשים שאולי התחברו אליך ואתה לא רוצה אותם יותר
- אתה יכול לבחור אפליקציה ספציפית - ולבטל את ההרשאות שלה.
(רן) אוקיי, אז זה סצנריו (Scenario) אחד שהוא אינטראקטיבי: יש User, הוא רוצה לעשות Log-In - הזכרנו כמה אופציות, הפחות מועדפת עלינו זה שם משתמש וסיסמא והקצת יותר מועדפת היא SSO.
יש עוד אופציות על המדף, דרך אגב, שנמצאות היום? חוץ משתי אלה - חוץ מ-SSO ו-User-Password?
- (אליעד) אה . . .
(רן) לא דברים שאתם רואים בשטח, אתה אומר . . . .
- (אליעד) לא ראיתי . . . בדרך כלל זה . . .
(רן) תמיד אפשר להמציא משהו, כמובן . . . .
- (אליעד) תמיד אפשר להמציא משהו - אבל עדיף שלא . . .
- אנשים אוהבים להמציא דברים, הם אוהבים לעשות דברים בדרך טיפה שונה - אבל הדרך הכי טובה זה להשתמש בדברים שקיימים עכשיו . . .
(רן) אז מקודם, כששאלתי אותך את השאלה של “איך מאבטחים API?” אמרת “תלוי” . . . אז קודם כל - זו תשובה שהיא תמיד נכונה . . . . אז הלכנו על ה-Flow האינטראקטיבי - ועכשיו בו נלך Server-to-Server, אוקיי?
אז יש, נגיד, איזשהו Service שרוצה, לא יודע - לקרוא את התמונות שלך ולחפש בהן תמונות של חתול ובסוף להציג לך אלבום תמונות של החתול שלך, אוקיי? אז זה Server-to-Server - איך עובדת שם האות’נטיקציה (Authentication)?
- (אליעד) נכון, אז פה אנחנו שוב חוזרים לעניין ה-OAuth - זה בדיוק מה שהוא בא לפתור
- הוא בא לתת לך הרשאות ספציפיות לאפליקציות מסויימות - לחשבון שלך.
- אז בעצם, כמו מה שאמרנו קודם - הוא ינפיק Token לאותה אפליקציה, שרוצה נגיד לעשות סטטיסטיקות על החשבון Twitter שלך או לא יודע מה - בתוך ה-Token . . .
- (אליעד) לגמרי . . . .
- הוא ינפיק לך Token, כשבתוך ה-Token ממש כתובות ההרשאות.
- דרך אגב - אני שם כאן Side-note - מה שמייחד כל כך Token-ים לעומת נגיד Cookies זה ש-Cookies, השימוש בהן להרשאות הוא . . . לא הייתי אומר “פחות טוב” אבל הוא תלוי-סיטואציה
- עקרונית, עם Cookies יש לך את הבעיה שאתה צריך לשמור את כל ה-Cookies שיצרת
- אתה מביא עכשיו Cookie לאיזה מישהו שהתחבר - אז אתה צריך לשמור את זה ב-DB ואז בכל פעם לבדוק האם ה-Cookie נמצא ב-DB
- שזה תהליך שלוקח זמן ולוקח מקום - זה טיפה מבאס . . . .
- אבל הקטע ב-Token-ים זה שהם . . . אתה יכול “לוודא אותם עם עצמם”
- ברגע שמישהו הביא לי Token וב-Token רשום “אני Admin!” - אז אתה יכול לדעת שאתה הנפקת את ה-Token הזה ואתה מאשר את זה שהוא Admin
- בתוך ה-Token רשומות כל ההרשאות שלו וכל “מי שהוא” . . .
(רן) - וזה באמצעים קריפוטוגרפיים . . . .
- (אליעד) נכון -באמצעים קריפטוגרפיים, בדיוק - מפתחות הצפנה וכל הדברים האלה.
- ככה אתה יכול לוודא בעצם את החתימות.
(רן) אוקיי, אז דיברנו על כמה Scenarios - ועצרנו ב-Server-to-Server
עכשיו, השאלה שלי היא האם אתם - כחברה - רואים את הדברים האלה קורים גם בתוך Datacenters? לצורך העניין - Service אחד ניגש ל-Service אחר ומבקש Token כדי לבקש רשות להשתמש ב-Data של ה-Service הזה . . .
במילים אחרות - איך מאבטחים את מה שקורה בתוך החברה עצמה? אורי מקודם רמז שם - “יש לי שם אלף microService-ים: אני לא רוצה שכל אחד מה-microService-ים יגש לכל סוג של Data. אני רוצה איכשהו לשלוט על מה שקורה שם” . . .
אני, בתור CISO, רוצה לדעת שאוקיי - יש Service שמתעסק אולי בניהול כרטיסי אשראי - אבל רק הוא. לאחרים אין גישה לזה. אוקיי?
איך מנהלים את האבטחה של . . . . לא נדבר על כל ה-Database והכל, אבל של ה-APIs בתוך אותו Datacenter - האם אלו דברים שאתם מתעסקים בהם שם?
- (אליעד) אז עקרונית, כשאנחנו עכשיו מסתכלים על רשתות של לקוחות ודברים כאלה, יוצא לנו לראות הרבה פעמים שפנימית, בתוך הרשת, אין כל כך מנגנוני אות’נטיקציות (Authentications) והרשאות.
- כי אנשים אומרים, ומתכננים אומרים, שזה משהו פנימי - לאף אחד אין גישה לזה מבחוץ, לפנות ל-API-ים הפנימיים האלה, שעכשיו שולפים לי מה-DB ועושים את כל הדברים האלה - אז למה אני צריך הרשאות שם?
- אני פשוט . . . לכל מי שיש לו גישה לשירות הזה - הוא יכול להוציא מה שהוא רוצה . . .
אבל בכל אופן - מי שכן טורח וכן רוצה לאבטח את . . . או לפחות לייצר איזשהו חיתוך בין השירותים הפנימיים שלהם?
- (אליעד) אז יש כל מיני דרכים לעשות את האיבטוח בין האפליקציות לאפליקציות
- בדרך כלל אנחנו רואים API Keys - הקונספט של API Keys, שהוא קצת שונה משם-משתמש וסיסמא, הוא שבסופו של דבר אתה מנפיק . . .
- אם מישהו נגיד רוצה להשתמש באיזשהו API מסוים, אז אתה מנפיק לו איזשהו API Key
- אתה רושם לעצמך שה-API הזה מאובטח ומאושר מבחינתך
- ואז הוא שם את ה-API הזה באפליקציה שלו או ב-Script שלו - וככה היא פונה, בעצם, לשירותים שלך.
(רן) אוקיי . . . אני מניח שזה גם משתנה יחד עם רמת המורכבות של החברה וגודל החברה - רמת המורכבות ואולי גם הרגולציה בתעשייה שבה היא נמצאת.
דרך אגב, יש רגולציות בתחום הזה? זאת אומרת - איפה זה נמצא, לצורך העניין, אם לא מימשתי את אבטחת ה-API שלי כמו שצריך? “יכנסו בי” אחר כך, ב-SEC או במשהו כזה?
- (אליעד) אז לגמרי . . .
- כמובן שיש את הארגון האירופאי הגדול שקוראים לו GDPR, שהוא אומר “אוקיי - עכשיו חשפת בטעות מידע של אנשים, עשית דברים שאסור לך לעשות - ואתה עכשיו נקנס על זה בהמון כסף” . . . .
- שזה דבר שחברות מאוד מפחדות ממנו . . .
(אורי) זה אם עשית דבר שאסור לך לעשות . . . . פה, לא אתה חשפת אלא נכנס תוקף וחשף את הפרטים של האנשים. זה עדיין חושף אותך?
- (אליעד) השאלה היא האם עדיין יש רגולציה על איך לאבטח את ה-API-ים?
(אורי) לאבטח, כן . . . .
- (אליעד) אז בתחום הזה, לא שאני מכיר רגולציה כזו ולא שראיתי משהו אחיד - בדרך כלל כל אחד עושה די מה שהוא רוצה . . .
- אולי בתחום הפדראלי (Federal) . . . בתחום הפדראלי, ברשויות ממשלתיות ודברים כאלה, יש להם . . .
(אורי) אני חושב שזה פשוט איזור שמאוד קשה לייצר בו רגולציה, כי הוא . . .
(רן) דינאמי . . .
(אורי) . . . מאוד דינאמי ומפתח . . .
(רן) רגולציות זה משהו שלוקח לו 20 שנה להגיע . . . אז אולי זה יקרה, אבל . . .
(אורי) הרבה פעמים, התעשייה או או התגובות לשכלולים של ה-Attackers הם אלו שקובעים את הטון. לדעתי, גם ככה Auditors או אנשים שצריכים להגיד בשביל החברה הזאת, ה-ICC, ש“החברה הזאת - אנחנו מאמינים במה שהיא אומרת” - אז הם גם רוצים לדעת שאתה עושה את כל מה שאתה צריך להגן על ה-Data שלך ולהגן על כל הדברים.
עכשיו, אין . . . . קשה להגיד שיש פה רגולציה, אבל לפחות הם ינסו לראות שאתה עושה “Best Effort” . . .
(רן) יש פה איזושהי “קונטרה”, לפחות זה . . . . “מישהו מסתכל עליך”
(אורי) כן, מישהו מסתכל עליך מבחוץ ואומר “אוקיי, אתה פועל בקודים סבירים”.
[עניין האיטיות יכול להיות זה נכון לגבי רגולציות פיננסיות - אבל לרגולציות “תהליכיות” כמו ISO למיניהם זה יכול להגיע קודם]
- (אליעד) צדקת במה שאמרת קודם - זה תחום שהוא גם חדש וגם קשה מאוד לעשות בו רגולציה.
- אם יבואו אליך ויגידו לך “תגיד לי - מה הם כל ה-APIs שמחזירים לך כרטיסי אשראי והאם אתה שולח את זה בצורה מאובטחת?” - קשה מאוד לדעת . . .
- רק עכשיו כל הנראות הזו מתחילה להיפרם פה . . . .
(אורי) זהו - אמרת קודם שזה יותר קשור ל-Visibility, והזכרת . . . אתם סורקים את כל ה-API-ים שיש לארגון - איך? זה נעשה אוטומטית? זה נעשה . . . אתה יודע - לסרוק Port-ים זה משהו פשוט - לעשות “++” על ה-Port Number - אבל API, יש לו חוזה, יש לו דרך שבה קוראים . . . בגדול, כשאתה מוציא API אז כתוב בתיעוד, אבל השאלה האם אתם יודעים אם יש API-ים שפתוחים החוצה, שהם לא מתועדים . . . .
- (אליעד) בדיוק . . . דברים כאלה המערכת שלנו גם מנסה למצוא.
- בסוף, חוץ מלמצוא את כל ה-API-ים שלך - דרך תקשורת או לוגים או לא משנה מה - אנחנו בעצם גם מציגים לך אותם . . .
- אנחנו גם מנסים להציג לך ולהתריע בפניך אם יש לך כל מיני מיס-קונפיגורציות (Misconfigurations) שהיו לך - API-ים ששלא היו אמורים להיחשף או API-ים שאין בהם אות’נטיקציה (Authentication) אבל אמורה להיות, או שהאות’נטיקציה (Authentication) לא נאכפת . . .
(רן) איך אתם בודקים את זה? איך אתם מתחברים למערכת ויודעים מה קורה בכל API?
- (אליעד) אז זה ממש תלוי, ממש תלוי פר ה. . .
- עקרונית, רוב המידע שאנחנו מקבלים זה ממידע שאנחנו רואים - אנחנו רואים את התקשורת ל-API-ים האלה
- החברה [הלקוח], בעצם בתהליך האינטגרציה (Integration) עם החברה שלנו, נותנת לנו אפשרות לראות את התקשורת שעוברת - ולהוציא מזה, בעצם, את ה-API-ים . . .
(רן) אוקיי, זאת אומרת שאת צריכים לעשות איזושהי אינסטרומנטציה (Instrumentation) - לחבר אתכם, איכשהו, לתוך ה-Stack שלהם . . .
- (אליעד) כן, הם מחברים אותנו לתוך הרשת שלהם או למערכות שלהם . . .
- תלוי ממש בארכיטקטורה - זה ממש על קצה המזלג . . . .
- זה יכול להיות שונה פר לקוח, לגמרי . . . .
- אבל בסוף הם נותנים לנו איזושהי ויזיביליות (Visibility), ואנחנו לוקחים את המידע הזה ומציגים אותו בחזרה ללקוח.
(רן) אוקיי
(אורי) רן קצת שאל על על תקשורת בתוך ה-Datacenter, בתוך ה-Domain של האפליקציה שלי. סגמנטציות (Segmentations) של רשת זה גם נחשב לאחד הכלים שלכם לא לחשוף API-ים החוצה או לא לחשוף את מה שלא צריך?
- (אליעד) האם אנחנו מזהים את ה . . . ?
(אורי) האם אתם מזהים או האם . . . אתה יודע, לפעמים יש לי שכבות של האפליקציה ואחת היכולות שלי, כדי לא או . . . כדי ש-API-ים מסויימים לא יחשפו החוצה, זה פשוט לשים אותם מאחורי עוד Firewall . . . .
(רן) אני חושב שאם הם [noname] עושים את זה - אז הם עושים טעות . . . אני לא יודע אם אתם [אליעד] עושים או לא עושים אבל . . . .
(אורי) מי? הם עושים טעות?
(רן) כן, כי הם מתמקדים בפאן האפליקטיבי (Application), ב-Security אפליקטיבי, שזה HTTP ו-OAuth והדברים כאלה, שזה סבבה - יש שם Business, יש שם משהו מעניין. מה שאתה [אורי] מדבר עליו פה זה ברמת ה-Networking, נגיד Level 4 פחות או יותר - ואלו לא אותם כלים . . . אני חושב שזה בסדר - לא יודע אם זה מה שאתם עושים או לא, אבל אם אתם [noname] לא עושים - אז לי לפחות זה נשמע הגיוני. זה לא אותם כלים - מה שאתה [אורי] מדבר אלו כלים מאוד “גסים”, ואני חושב שצריך איזשהו שילוב של הכלים. אבל אתה יודע - זה פעם אחת לבוא עם מחרשה ופעם אחרת לבוא עם פינצטה . . .
(אורי) זה בדיוק מה שאני שואל - האם זה נמצא בסט-הכלים, גם מבנה הרשת או . . .
- (אליעד) מבנה הרשת . . . היום הכל טיפה השתנה - היום הכל ב-Cloud, היום הכל ב-AWS.
- יש קונפיגורציות (Configurations) להכל ואתה יודע אילו שרתים מחוברים לאילו שרתים, אתה יודע איזה API-ים יש על כל מיני שרתים - הכל הוא הרבה יותר . . .
- לא יודע אם “קל” יותר לדעת, אבל כן אפשר “לשאוב” את המידע הזה ברגע ש . . . . אם הלקוח נותן לנו את האפשרות.
- ואנחנו יכולים להציג לו את זה, לגמרי - אנחנו יודעים אם API-ים שלא אמורים להיות פתוחים לאינטרנט פתוחים לאינטרנט או שאמורים לעבור דרך Load-Balancer ולא עוברים דרך Load-Balancer ואתה יכול להשתמש בהם ישירות
- אנחנו יודעים את זה ואנחנו יודעים להציג את זה ללקוח כמיסקונפיגורציה (Misconfigurations) בעצם.
(רן) יצא לכם לראות . . . . אולי תוכל לספר ככה על כל מיני “טעויות טיפוסיות” שאתה רואה בשטח? זאת אומרת, אתה יודע - המפתח התכוון למשהו טוב אבל יצא לו “X”, ואתה כבר ראית את זה כבר מאה פעמים, אז אולי תוכל למנוע את הפעם המאה-ואחת? או לחילופין . . . .
(אורי) “Best Practices” . . . .
- (אליעד) אוקיי, אז הרבה דברים שראינו זה שמטמיעים סיסמאות או כל מיני דברים כאלה - באפליקציות “שיורדות ללקוח”
- כלומר - שבאפליקציות עצמן יש, נגיד, את ה-API Key, שאולי לא אמור להיות חשוף
- כי בסופו של דבר המפתח אומר “אוקיי, אני מפתח פה אפליקציה, היא תיגש לכל מיני שירותים עם ההרשאות של המשתמש - אבל יש לה פה גם את ה-API Key הזה, כך שהיא יכולה לגשת עכשיו ל-API-ים פנימיים שלי”
- ומבחינתו זה “סוד” . . . .
(רן) לצורך העניין, כשאתה אומר “אפליקציה” בהקשר הזה אז אתה מתכוון ל-iPhone או Android או Web . . .
- (אליעד) או Web אפילו . . .
(רן) או Web . . . .אבל זה לגמרי פתוח, זאת אומרת - ברגע ששמת את זה ב-AppStore, אפשר לעשות . . . להריץ Strings ולמצוא את כל ה-String-ים
- (אליעד) בדיוק
- אני יכול להגיד לכם שראיתי מלא פעמים שגם עם כל החבילות ועם כל ה-JavaScript-ים שאנשים מורידים ללקוח
- אז יש לקוחות ששמים בתוך ה-JavaScript-ים שלהם פתאום מפתחות של כל מיני . . . של S3 Buckets וכאלה
- וזה נמצא פשוט בתוך ה-JavaScript
- ולפעמים זה פשוט נשלח באות’נטיקציה (Authentication), בלי שום קשר . . . .
- גם אם ה-API עצמו לא צריך את האות’נטיקציה (Authentication) הזאת בכלל - זה נשלח . . .
- ואז נוצר מצב של המון המון זבל . . . . אתה מסתכל על ה-API ואתה רואה עשרה סוגים של אות’נטיקציה (Authentications) שונים שעוברים שם . . .
- ואתה אפילו לא יודע מה נכון לאותו API . . .
(רן) אז אתה אומר שעד כמה שזה נשמע טריוויאלי - אל תשימו את המפתחות שלכם אצל הלקוח, אצל המשתמש - ועדיין עושים את זה . . . [להוסיף את זה למסמך Onboarding]
- (אליעד) עושים את זה . . .
- ועוד משהו שעושים . . .
(רן) דרך אגב - לכם יש כלים שיכולים לעזור למנוע את זה או שזה כבר Business אחר? . . .
- (אליעד) זה . . . . אנחנו כמובן בתוך העולם של האות’נטיקציה (Authentication), אנחנו רואים אילו אות’נטיקציות נשלחות ל-API מסויים ואנחנו מתריעים אם אנחנו רואים משהו שהוא לא תקין
- אם יש איזה בעיה באות’נטיקציה (Authentication), אם יש איזו אות’נטיקציה (Authentication) שנשלחת והיא בכלל לא נאכפת . . .
- אז אנחנו כן מתריעים על זה ללקוח.
(רן) כן, בסדר - אבל אתם מתמקדים בעיקר ב-Network ולא ב-Source Code . . . אולי זו שאלה לא טיפוסית אבל . . .
- (אליעד) לא, אנחנו לא נכנסים לתוך ה-Source, לפחות עכשיו . . .
(רן) אוקיי - מה עוד?
- (אליעד) עוד משהו שאנשים עושים זה לשלוח את ה-Token-ים או את ה-API Keys ב-URL, ב-Query Parameters של ה-URL . . .
- שעל פניו זה נראה . . . “מה זה משנה אם זה בתוך ה-Header או ב-Body או ב-URL, זה לא כל כך משנה”
- אבל אותו URL יכול להישמר ב-Log של איזה שרת-Proxy באמצע - שזה דבר שאתה אפילו לא חושב עליו בתור מפתח -
- ובאותו שרת- Proxy, אם אני עכשיו אסתכל ב-Log-ים שלו, אני אראה שם מלא Access Tokens, מלא API Keys - שאני יכול עכשיו להשתמש בהם
- וזה דבר שעדיף לא לעשות אותו . . . . לא לשלוח דברים רגישים ב-Query Parameters, כי יש מצב שזה נשמר איפשהו.
- וזה לא דבר שהיית רוצה שישמר . . .
(רן) זה גם לא מוצפן . . . זאת אומרת - ה-URL עצמו לא מוצפן, גם אם אתה ב-HTTPS . . .
- (אליעד) נכון - הוא נשמר ב-Log כמו שהוא, אלא אם כן שלחת ממש . . .
(רן) דרך אגב - Header-ים מוצפנים? אני כבר לא זוכר . . . . ב-HTTPS?
- (אליעד) עקרונית כן . . . ב-HTTPS עקרונית הכל מוצפן, ואתה לא תראה שום דבר ממה ש . . .
- אבל שוב - אם אתה עובר דרך Proxy ב-HTTPS אז הוא חייב לפתוח את ההצפנה . . .
- כל הקטע פה זה שהוא כן פותח את ההצפנה וניגש במקומך לשרת שאתה רוצה.
- אז הוא כן רואה מה עשית . . .
(רן) כן . . .
בסדר, אז תראה - דיברנו ונהנינו ופתאום עבר לנו הזמן . . .
ככה לפני שנסיים - אורי, היו לך עוד כמה מילים על החברה-ללא-שם? קודם כל - אני מאחל לכם שבקרוב תמצאו שם . . . .
איפה אתם נמצאים בישראל?
- (אליעד) אנחנו בתל אביב - ב-Midtown, ליד עזריאלי.
- ממש במרכז . . .
(רן) טוב - אני מניח שאתם מחפשים לגייס אי-אילו . . . .
- (אליעד) וואו - המון . . . “בואו בהמוניכם”, חברה מדהימה.
(רן) תגיד בשתי מילים מה אתם מחפשים?
- (אליעד) אנחנו צריכים . . . מה, איזה סוג של אנשים?
(רן) כן - באילו מקצועות, מה . . .
- (אליעד) Frontend ו-Backend ו-DevOps . . . חוקרים מדהימים יש כמובן - מוזמנים.
- כמעט הכל, האמת . . . .כמעט הכל
- יש מחסור באנשים טובים בשוק.
(אורי) להתחיל למרוח פה מלח על הפצעים? . . .
- (אליעד) רופאים . . .
(רן) טוב, אליעד - תודה רבה! היה מרתק. להתראות.
האזנה נעימה ותודה רבה לעופר פורר על התמלול!
Reversim Podcast, episode number446 - At the end of August, Ori and Ran host Eliad from noname to talk about APIs and how to secure APIs on the Web - and not just on the Web.
- (Eliad) Not only on the Web but also between apps, the use of APIs has become very wide-spread lately.
(Ran) excellent - so before we talk about APIs, let's get to know Eliad a bit -
- So I'm Eliad, as you said - I'm 26 years old, from Tel Aviv.
- In principle, most of the years I worked in the field of IR - which is Incident Response
- Actually there - you encountered an event, you researched it
- You checked what the attacker did on the network - where he came from, what files he touched
- And you were actually acting in the hat of - I would say like a "police detective" - of the internet world...
(Ori) I was caught for a moment for . . . “Most of my life I have worked in . . “. Well - you are half my age . . . .
- (Eliad) most of my life...
(Ran) I actually thought more towards Sherlock Holmes . . .
- (Eliad) Yes . . . . So that's about the last five or six years, I've been working on Incident Response.
- After that, I wanted to make a little change in my work - and I went more to the field of research
- I wanted to explore something that is now interesting - that now everyone is using
- And I've seen that the whole field of Cloud and APIs and all these things - it's really going to be the hottest thing now: APIs have started to take up a lot of space now in our lives
- Between apps, between apps and DBs, between Clients and Servers - everything now is transferred with the help of APIs.
- And this world became very interesting - and so I started . . .
- Then I joined the research team at noname
- And the company - its goal is to make API Security, when the product gives you three things:
- One is the visibility on your APIs - what APIs you have, what are their schemes, where there are authentications - all these things.
- It's a pretty messy world - usually, if you went to corporate CISOs or people like that, and you said to him, "Say, how many APIs do you have?" - he doesn't know, he's not sure about it.
- "Which one do credit cards go through?" or "In what authentications?" - things like that - "I don't know" . . . . .
- This whole world is very messy, and basically what the system does at the beginning is bring you some visibility on all your APIs.
- On top of that . . .
(Ran) Are we talking about outward-facing APIs? - Let's say, in the context of a credit card for example - or are you also talking about everything that happens "inside"?
- (Eliad) So also "Inside" - any use of APIs, even if we say, in the most familiar and broad use, it is a programmer who builds some kind of Web application and people access it through the browser or through their phone, and then basically there are all kinds of APIs that return to you information that the app requests or that the browser requests.
- Then it is displayed on the screen, for the user.
- So these are the most recognizable APIs . . .
(Ran) ok . . . Anyway, we're talking about "over-the-network", right? We’re not talking about internal things, which happen inside the process?
- (Eliad) So no - it's not those APIs . . . It's Web-APIs, it's APIs that go through the computer itself.
(Ori) Okay, not inside the computer itself - but it could be that . . . I mean, I'm a company and I expose some kind of app, but beyond the app or APIs that I expose out, I have more...
(Ran) microServices . . .
(Ori) . . . a million-and-one microservices that talk to each other in APIs - which is basically "the contract between them", also on...
- (Eliad) That’s true - so if you now have some kind of a DB, or no matter what you opened - everything that communicates via APIs...
- Now also between apps - also between apps you can communicate between APIs, both the apps and the DBs, when you index and when you return information and do all kinds of retrievals - everything now goes through APIs.
- So that's exactly the intention - any kind of Web-API that goes through
- But not RPC, for example - if anyone here is familiar with Remote Procedure Call - then it's not like that, but APIs that are specifically related to the Web.
- (Eliad) Okay, so it's a bit funny story, when I heard it ...
- In principle, when they opened the company - the founders - they immediately wanted to talk to investors and get investments and financings and all that, and then they didn't have a name yet.
- And in the emails they sent to investors, they wrote to them that "It's a noname API Security company" - with the intention of saying it doesn't have a name, yet.
- And the replies they got were mostly “Wow! noname - what a great name!” . . .
- So they said ok ... So that's the name.
(Ran) It's good that they didn't put <triangular brackets>, as they usually do - it was very difficult to pronounce it...
Ok, so look - we have quite a few things that we're going to talk about and we won't be able to talk about the whole security world of APIs, so let's pick a few things here.
Let's start with this: I'm now creating an outward-facing API and I want to secure it. What are my options? What tools? What are the “Cool Guys” doing today to secure APIs?
- (Eliad) Okay, so first thing - and this is the most important thing - first of all I should figure out who are the users of my API?
- Who consumes it and for what purposes it is consumed for.
- Because you have lots and lots of types of authentications and authorizations and things like that - and you need to know exactly who the API is aiming for-
- If it's for users in the browser
- If it's between apps
- If it's between the app and DB
- And things like that.
(Ran) Okay, so let's say a browser: I'm writing a backend-service that serves a Frontend that's in the browser - and it's mine - both are mine - and I need to secure this whole story.
What do I do?
- (Eliad) First thing - at the end, when you build some kind of a website, then you are connected, say, with a username and password, that's how you connect to your site
- And you issue a token to the person who has logged in to you - or even bring them a cookie - that they're actually accessing your website with, that’s the common case.
- And you reserved it in a DB, in some form, its permissions - and that's how you manage it...
(Ran) Cool, that's by and large - but of the protocols that exist today - OAuth and ... Let's see what...
- (Eliad) So let’s go really deep, OK ...
- Let's differentiate between authentication and authorization, because a lot of people get confused about it.
- By Authentication, we mean user verification – verification of the identity of those who are now coming and using this API.
- And Authorization means what permissions that user has – whether they can access that resource or do something in my app.
- So let's start with authentications a bit - I think I already said a moment ago that the most familiar thing is to send a username and password
- Then you get back either a token or a cookie
- Soon we will talk a little bit about the difference between a token and cookie - what is the use of each one
- And then with it you continue to access the same site - and that's how you basically replaced authentication with [another] authentication.
- You've replaced your username and password with your token – and then you send it.
(Ran) Okay, it's just like "build your own" ... Username, password - every website needs . . . The user needs to generate a username and password for each site, and there is quite a bit of "technical debt" here ....
- (Eliad) True, there is a very big problem with usernames and passwords ...
- One - if I'm now a customer of hundreds of sites: I have Facebook and Google and I have a lot...
- "A million sites" - and for each of them you need to remember the password
- And more than that - who guarantees to me that my password will be secure enough? Who guarantees that there is no one who could come and can take my password?
- If I used a relatively simple password like "Apple" or I-don't-know-what, people can just come and sign in to my account.
- So even the fact that you trust your user to create for you [for him/herself] the password and identification for your website - that's not good enough.
- There are a few ways you can deal with this
- One of them is Two Factor Authentication (2FA)
- The idea is that if someone eventually both obtained the username and the password - the attackers somehow got them - they still won't be able to log in to the account, because an SMS message still needs to be sent to that person's phone, and they need to confirm the login.
- This already prevents them from gaining access to the same account.
- Today there are also more advanced protocols - one of them is SSO, which is Single-Sign-On
- And the reference here is to a completely new concept, which really changed this world - it basically means that there is no more username and password for every site
- There's one “major website” which acts as the "identity manager" - it’s actually listed by all the people
- Everyone logs in to it and everyone has a username and password - and usually it's also with Two Factor Authentication so it's also very difficult to steal your identity from there
- And any other website you visit will actually verify your identity with that third-party site.
- Let's say, if Facebook is now the identity provider and I want to log in to another app - then you'll see a button for "Sign-in with Facebook" and there's actually some process where Facebook verifies my identity - it will be my verification for that site, and not the username and password for that site.
(Ran) So maybe there is not a single SSO Provider - I mean it's not just Facebook, there are a few more of them in the world - you can choose whether it's Facebook or Google or Twitter or LinkedIn or Whatever, But there are some big ones - and by and large each user chooses where to manage their identities, and of course you don't have to choose once but you can choose for each site someone else.
But what does it mean? How does it work from the point of those who implement it? If I now want to use SSO with my service - what protocol do I use with Facebook or Google?
- (Eliad) So usually ... The protocol that is currently pretty common is called OAuth
- In principle, OAuth is not for Single-Sign-On purpose, but for another purpose that we will now elaborate on a bit -
- Imagine that you have a Twitter account—and you want to give some third-party app permissions to your Twitter account because you want it to do all sorts of account statistics or things like that.
- So let's put it this way - "in the world of yesteryear" you had to transfer your username and password to the app
- It would get full permissions to your account - it could change password, it could do anything ... Post on your behalf, read your private messages . . . .
- Which was a bad thing to do ....
- (Eliad) Don't do it ... Do not to give your username and password to any app and any website and anything ...
- so OAuth ...
(Ran) We had to say that, didn't we? . . . . that no one would think by mistake ....
(Ori) No, you can give someone for their service - but don't let the third-party service ...
- (Eliad) Yes, don't give the third-party service your permissions....
(Ran) So by the way - even if your bank asks for the username and password: guys, don’t .... First of all, it's probably a scam, and if it's really the bank - then switch to another bank ... They shouldn’t do that.
Ok, so you say - SSO and OAuth is ... Perhaps this was not the intention originally but it is a way nowadays to implement SSO ...
- (Eliad) so I'm going to elaborate a bit on this - OAuth came and solved this part of authorization management
- It came and said, "Okay, I'm going to give some sort of a token that will contain account-specific permissions."
- And it seems to me that everyone knows - that you sometimes go through some site to another site, and you use" Sign-in with Google" -
- So Google opens a window for you and tells you that there's an app - and that's the name of the app - and it's now asking for certain permissions for your account-
- Asking to read messages, asking to see your email and profile ...
- And it declares - "It won't be able to publish things on your behalf"
- And that's exactly the idea of managing permissions—you have account-specific permissions, which you can pass on to a specific app.
- And if we go back to the Single-Sign-On-to-OAuth section, some kind of extension has been introduced, called OpenID Connect (OIDC)
- They said, "If we already have this whole identity management thing, and I trust a third party to authenticate me – then let's implement a Single-Sign-On already as well"
- Let's already "use this protocol" and do a Single-Sign-On.
- So it's basically this implementation.
(Ran) Ok .... And once I did Sign-in - so they have these permissions forever, or is there some sort of protocol here for when it expires, etc.?
- (Eliad) So usually, the idea of tokens is that they won't exist forever . . . .
- Usually they would put them ... There can be tokens that stay alive for an hour or 24 hours, depending on the website that issued them.
- And once they've issued you the token, they also issue something called a refresh token with it.
- That every time the token expires, you can send the refresh token and get a new one.
- And so, when I logged into Facebook once, let's say — or through Facebook once — they wouldn't have to ask me to do it again.
- They have the token and they change it every time.
- And something else, specific to this mechanism - what's so good about it is that you can also use Revoke, specificaly for the app you want
- You don't have now to change your username and password to turn off the connections of apps which may have connected to you and you don't want them anymore
- You can select a specific app—and revoke its permissions.
(Ran) Okay, so this is one scenario that is interactive: there is a user, he wants to do Log-in - we mentioned some options, our least favorite is username and password and the little more preferred one is SSO.
Are there any other options on the shelf, by the way, that are available today? Apart from these two - apart from SSO and User-Password?
- (Eliad) Ah ...
(Ran) Not things you see on the ground, you say ....
- (Eliad) I didn't see ... Usually it is ...
(Ran) It’s always possible to invent something, of course ....
- (Eliad) You can always invent something - but it's better not to ...
- People like to invent things, they like to do things in a slightly different way - but the best way is to use the things that exist now ...
(Ran) So earlier, when I asked you the question of "How do you secure an API?" You said "it depends" . . . So first of all - this is an answer that is always true .... So we went for the interactive Flow - and now let's go to Server-to-Server, OK?
So there's a service that wants, I don't know - to read your pictures and search them for pictures of a cat and end up showing you a photo-album of your cat, OK? So it's a Server-to-Server - how does Authentication work there?
- (Eliad) That's right, so here we go back to the OAuth issue again – that's exactly what it came to solve
- It comes to give you specific permissions for certain apps — to your account.
- So basically, like what we said before - it will issue a token to that app, which wants to, say, run statistics on your Twitter account or I don't know what - within the token ...
- (Eliad) Totally ....
- It will issue for you a token, with the authorizations actually written inside the token.
- By the way - I’ll put a side-note here - what makes tokens so unique compared to, say, cookies is that cookies - their use for permissions is ... I wouldn't say "less good" but it's situation-dependent
- In principle, with cookies you have the problem that you need to keep all the cookies you have created
- You are now bringing a cookie to somebody who has logged in - so you need to save it in the DB and then each time check if the cookie is in the DB
- Which is a process that takes time and takes space - it kind of s@#*ks ....
- But the thing about tokens is that they are ... You can "verify them against themselves"
- Once someone has brought me a token and a registered token with "I'm Admin!" - then you can know that you have issued this token and you can confirm that it is an Admin
- Within the token are listed all its permissions and all about "who it is" . . .
(Ran) - and this is done by cryptographical means ....
- (Eliad) right - by cryptographic means, exactly - encryption keys and all those things.
- That way you can actually verify the signatures.
(Ran) Okay, so we talked about some scenarios - and we stopped at Server-to-Server
Now, my question is, do you – as a company – see these things happening within datacenters as well? For that matter- one service accesses another service and asks for a token to ask for permission to use that service's data...
In other words - how do you secure what is happening within the company itself? Ori earlier hinted about that - "I have thousands of microServices there: I don't want every one of the microServices to access any kind of data. I want to somehow control what's going on there"...
I, as a CISO, would like to know that OK - there is a service that deals with credit cards management - but only it. Others don't have access to it. Ok?
How to manage the security of .... We're not going to talk about all the databases and everything, but of the APIs within the same datacenter - are these things the staff you're dealing with there?
- So in principle, when we now look at customer networks and things like that, we get to see a lot of times that internally, within the network, there are not so many authentications and permissions mechanisms.
- Because people say, and planners say, that it's something internal - nobody has access to it from the outside, to access to these internal APIs, which are now pulling me out of the DB and doing all these things - so why do I need permissions there?
- I just ... For anyone who has access to this service - he can take out whatever he wants...
(Ran) The so-called Famous Last Words .... "I don't understand what their interest is in passing through here in this heat .....
But anyway - those who do bother as well as want to secure ... Or at least produce some kind of cut-off between their internal services?
- (Eliad) So there are all kinds of ways to make the security between the apps and the other apps
- Usually, we see API Keys - The concept of API Keys, which is a bit different from username and password, is that you end up issuing ...
- If somebody, say, wants to use some particular API, then you issue them some kind of API Key
- You write down that this API is secure and certified for you
- And then he puts that API in his app or in his script— and that's how it turns, basically, on your services.
(Ran) Ok ... I guess it also differs along with the level of complexity of the company and the size of the company - the level of complexity and perhaps also the regulation in the industry in which it is a part of.
By the way, are there any regulations in this area? I mean - what happens, for that matter, if I haven't implemented my API security properly? Will they "get into me" later, the SEC or some other organization like that?
- (Eliad) So totally...
- Of course, there's the big European organization called GDPR, which is saying "Ok - now you accidentally exposed people's information, you did things you shouldn't do - and you're now fined for it with a large sum of money" ....
- Which is something that companies are very afraid of ...
(Ori) It’s only if you have done something that you are not allowed to do .... Here, you did not reveal anything, but an attacker penetrated and revealed the details of the people. Does it still expose you?
- The question is . . . is there still regulation in this case, on how to secure the APIs?
(Ori) Secure, yes ....
- (Eliad) So in this area, I'm familiar with such regulations and not that I've seen anything in particular - usually everyone does pretty much what they want ...
- Perhaps in the Federal sphere . . . In the Federal sphere, with governmental authorities and things like that, they have...
(Ori) I think it's just an area where it's very difficult to regulate, because it is ...
(Ran) Dynamic ...
(Ori) . . . very dynamic and key ...
(Ran) Regulation is something that takes 20 years to get ... So maybe it will happen, but ...
(Ori) Many times, the industry or the responses to the improvements of the attackers are what sets the tone. In my opinion, auditors or people who need to “speak for” this company, the ICC, that "this [my] company - we believe in what they say" - so they also want to know that you're doing everything you can to protect your data and protect all things.
Now, there is no .... It's hard to say there's regulation here, but at least they'll try to see that you're doing "Best Effort" ...
(Ran) There's some kind of "feedback" here, at least that. . . " Someone is looking at you."
(Ori) Yes, someone looks at you from the outside and says, "Okay, you're operating with reasonable codes."
[The matter of slowness may sometimes be the same as with financial regulations - but for "process" regulations such as ISO of all kinds, it might come faster]
- (Eliad) You were right in what you said earlier - this is an area that is both new and very difficult to regulate.
- If they come to you and tell you "tell me - what are all the APIs that return you credit card numbers and do you send them securely?" - it's very hard to tell...
- It's only now that all this visibility is starting to unravel here ....
(Ori) That's it - you said earlier that it's more about visibility, and you mentioned ... You scan all the APIs the organization has - how? Is it done automatically? This can be done ... You know - scanning Ports is something simple - add "++"on the Port Number -but API, it has a contract, it has a way of being addressed . . . Basically, when you use an API then it says in the documentation, but the question is do you know if there are APIs that are exposed externally, that they are not documented....
- (Eliad) Exactly ... these are things which our system also tries to find.
- In the end, besides finding all your APIs - through communications or logs or whatever - we actually show them to you as well...
- We also try to approach you and alert you if you have all kinds of misconfigurations that you use - APIs that shouldn't have been exposed or APIs that don't have authentication but should have, or that the authentication isn't enforced...
(Ran) How do you check it? How do you connect to the system and know what's going on in each API?
- (Eliad) so it really depends, really depends per the...
- In principle, most of the information we get is from the information we see - we see the communication to these APIs
- The company [the client], basically in the process of integration with our company, gives us the option to see the communication that goes through - and to take out of it, basically, the APIs...
(Ran) Okay, I mean you have to do some kind of instrumentation - to plug you in, somehow, into their stack...
- (Eliad) Yes, they connect us into their network or their systems ...
- Really depends on the architecture - it's right in a nutshell ....
- It can be different per customer, totally....
- But in the end, they give us some kind of visibility, and we take this information and present it back to the customer.
(Ran) Ok
(Ori) Ran asked a bit about communication within the datacenter, within the domain of my App. Does Network segmentations also considered one of your tools, in order not to expose APIs out or not to reveal what is not needed?
- (Eliad) Do we recognize the ...?
(Ori) Do you recognize or do you have . . . You know, sometimes I have layers of the app and one of my options, so as not to or . . . So that some APIs don't get exposed externally, it's just putting them behind another Firewall....
(Ran) I think that if they [noname] do it - then they are making a mistake ... I don't know if you [Eliad] do that or don't but....
(Ori) Who? Do they make a mistake?
(Ran) Yes, because they focus on the application aspect, the app security, which is HTTP and OAuth and things like that, which is great - there's business there, there's something interesting there. What you [Ori] are talking about here is at the networking level, say Level 4 More or less - and these are not the same tools ... I think it's ok - I don't know if that's what you're doing or not, but if you [noname] don't - then to me at least it makes sense. these are not the same tools - what you [Ori] are talking about are very "crude" tools, and I think you need some kind of combination of the tools. But you know - there’s one time to come with a plow and another time to come with tweezers...
(Ori) That's exactly what I'm asking - is it in the toolkit, also the network structure or ...
- (Eliad) Network structure . . . Today everything has changed a bit - today everything is in the Cloud, today everything is in AWS.
- There are configurations for everything and you know which servers are connected to which servers, you know which APIs are on all kinds of servers - everything is much more...
- Don't know if it's "easier" to know, but you can "pump" this information as soon as . . . . If the customer gives us the option.
- And we can show it to him, totally - we know if APIs that aren't supposed to be open to the internet are open to the internet or are supposed to go through Load-Balancer and don't go through a Load-Balancer and you can use them directly . . . .
- We know this and we know how to present it to the customer as misconfigurations.
(Ran) Let’s see .... Maybe you can tell us about all sorts of "typical mistakes" you see in the field? I mean, you know - the developer meant something good but it came out to "X", and you've already seen it a hundred times, so maybe you can avoid the one hundred-and-one time? Or alternatively....
(Ori) “Best Practices” . . . .
(Ran) Yes, or alternatively - "Stories from the trenches"..... “Battle Stories”, that you got to witness.
- (Eliad) Okay, so a lot of the things we've seen are about embedding passwords or all sorts of things like that - in apps that go down to the customer.
- That is - that in the applications themselves there is, say, the API Key, which should not be exposed
- Because eventually the developer says, "Okay, I'm developing an app here, it's going to access all kinds of services with the user's permissions - but it also has this API Key here, so it can access my internal APIs now."
- And for him it's a "secret" ....
(Ran) For that matter, when you say "app" in this context then you mean iPhone or Android or Web ...
- (Eliad) or even Web...
(Ran) or Web . . . . But it's totally open, I mean - once you've put it in the AppStore, you can do ... Run Strings and find all strings
- (Eliad) exactly
- I can tell you that I've seen a lot of times that even with all the packages and with all the JavaScript that people download to the customer
- So there are customers who put inside their JavaScript suddenly keys of all kinds . . . of S3 Buckets and such
- And it's just inside the JavaScript
- And sometimes it's just sent in authentication, which got nothing to do with it....
- Even if the API itself doesn't need this authentication at all - it's being sent...
- Then we have situation where we see that lots and lots of rubbish was created .... You look at the API and you see ten different types of authentications going through there...
- And you don't even know what's relevant for that API ...
(Ran) So you say that as trivial as it may sound - don't send your keys to the customer, at the user - and people still do it...
- (Eliad) They do it . . .
- And something else you do ...
(Ran) By the way - do you have any tools that can help prevent this or is it already another business?....
- (Eliad) It’s .... We are of course in the field of authentication, we see which authentications are sent to a particular API and we alert the customer if we see something that is not right.
- If there is some problem with authentication, if there is some kind of authentication that is sent and but not enforced at all...
- So we do alert the customer about it.
(Ran) Yes, ok - but you focus primarily on the Network and not Source Code ... Maybe it's not a typical question but...
- No, we don't go into Source code, at least for now ...
(Ran) Okay - what else?
- Another thing that people do is send the tokens or the API Keys in the URL, in the Query Parameters of the URL . . .
- On the face of it it looks... "What difference does it make if it's in the Header or in the Body or in the URL, it doesn't matter that much"
- But the same URL can be stored in the logs of some proxy server in the middle - which is something you don't even think about as a developer-
- And on the same proxy-server-, If I now look at its logs, I will see full name Access Tokens, Full API Keys - and I can now use them
- And this is something that is better not to do it .... Do not send sensitive things in Query Parameters, because there is a situation that it is stored somewhere.
- And this is not something you would want to be stored anywhere ...
(Ran) It's also not encrypted ... That is to say - the URL itself is not encrypted, even if you are in HTTPS ...
- (Eliad) That is correct - it is saved in the log as is, unless you actually sent ...
(Ran) By the way- Headers are encrypted? I can't remember .... in HTTPS?
- (Eliad) In principle, yes ... In HTTPS in principle everything is encrypted, and you will not see any of that ...
- But again - if you go through a proxy-HTTPS, then it must open the encryption...
- The whole point here is that it does decipher the encryption and go on your behalf to the Server you want.
- So it does see what you did ...
(Ran) Yes ...
Ok, so look - we were talking and having fun and suddenly time passed ...
Where are you located in Israel?
- (Eliad) We are in Tel Aviv - in Midtown, near Azrieli.
- Right in the center ...
(Ran) Well - I guess you're looking to recruit ....
- (Eliad) Wow - a lot... "Come in droves", it’s an amazing company.
(Ran) In two words - what you are looking for?
- (Eliad) We need ... you mean what kind of people?
(Ran) Yes - in what professions, what ...
- (Eliad) Frontend and Backend and DevOps . . . Amazing researchers of course - you’re all invited.
- Almost everything, that’s the truth .... Almost everything
- There is a shortage of good people in the market.
(Ori) Should we start smearing salt here on the wounds?....
- (Eliad) Physicians ...
(Ran) Well, Eliad - thank you very much! It was fascinating. Goodbye.