אפליקציות אינטרנט מבודדות (IWA) מספקות מודל אבטחה שמאפשר לאפליקציות אינטרנט לגשת ליכולות מתקדמות – כמו Direct Sockets ו-Controlled Frame – שבדרך כלל מוגבלות באינטרנט הרגיל. מכיוון שאפליקציות אינטרנט מתקדמות פועלות בסביבה שבה יש רמת אמון גבוהה, הן חייבות לפעול בהתאם למדיניות מחמירה בנושא אבטחה ופרטיות. ההנחיות האלה נועדו להבטיח שככל שפלטפורמת האינטרנט תהיה חזקה יותר, המשתמשים יישארו בטוחים והסביבה של הדפדפן תישאר תקינה.
מודל האמון של IWA
הליבה של פלטפורמת IWA מבוססת על מדיניות טכנית מחמירה שמחייבת את המפתחים לשמור על רמת אבטחה גבוהה. אפליקציות אינטרנט רגילות מסתמכות על מודל הרשאות גמיש, אבל אפליקציות אינטרנט מבודדות (IWA) נחתמות באופן קריפטוגרפי ומועברות באמצעות Web Bundles, מה שמאפשר לאמת את המקור והתקינות שלהן.
בתמורה לזהות המאומתת הזו, אפליקציות IWA מקבלות גישה לממשקי API עם הרשאות מיוחדות. כדי לשמור על האמון הזה, המפתחים צריכים לפעול לפי גישה שמתמקדת באבטחה, ולעמוד בדרישות של מדיניות מחמירה יותר – כולל מדיניות אבטחת תוכן (CSP) וסוגים מהימנים – שמבטיחה את בטיחות המשתמשים גם כשהם משתמשים ביכולות מתקדמות. כלומר:
- שקיפות: המשתמשים לא צריכים להיות מופתעים מהשימוש של האפליקציה בממשקי API עם הרשאות מיוחדות.
- הרשאה מינימלית: אפליקציות צריכות לבקש ולהשתמש רק ביכולות הספציפיות שנדרשות למטרה המוצהרת שלהן.
- שלמות סטטית: כל הלוגיקה שניתנת להרצה חייבת להיות עצמאית בחבילת האפליקציה כדי לאפשר ביקורת אבטחה ולמנוע התקנה ממקור לא רשמי של קוד זדוני.
אפליקציות IWA כוללות אמצעי הגנה מובנים חזקים, כמו מדיניות אבטחת תוכן (CSP) מחמירה שמונעת הפעלה של סקריפטים חיצוניים. עם זאת, מגבלות טכניות לבד לא יכולות לצמצם כל סיכון. גם בסביבה עם רמת אמון גבוהה, דפוסי הטמעה מסוימים או בחירות של מפתחים עלולים לסכן את הבטיחות או הפרטיות של המשתמשים. במדריך הזה מפורטים התרחישים המוגבלים האלה והמדיניות שחלה על השימוש בממשקי API עם הרשאות.
למה ההנחיות האלה חשובות
הקפדה על המדיניות הזו היא לא רק עניין של תאימות – היא גם תורמת לבניית מערכת אקולוגית בת-קיימא לאפליקציות אינטרנט מתקדמות. אם תפעלו לפי ההנחיות האלה, תוכלו לוודא שהאפליקציה שלכם:
- מונע רגרסיות אבטחה: מונע נקודות חולשה כמו פרצת אבטחה XSS (cross-site scripting) והרצת קוד מרחוק, כי הלוגיקה מוגבלת.
- הגנה על פרטיות המשתמשים: המערכת מבטיחה שנתונים רגישים וגישה לחומרה יטופלו רק בהסכמה מפורשת של המשתמשים ובשקיפות.
- שמירה על אורך החיים של הפלטפורמה: עוזרת לשמור על סטנדרטים גבוהים של אבטחה שנדרשים כדי להמשיך להרחיב את מערך היכולות של פלטפורמת IWA.
עקרונות ליבה
שקיפות וכוונת המשתמש
הכלל הכי חשוב הוא: אל תפתיעו את המשתמשים. ההתנהגות של האפליקציה צריכה להתאים למטרה המוצהרת שלה ולציפיות של המשתמשים.
- להישאר במסגרת: אל תטמיעו פונקציונליות שחורגת מהמטרה הברורה של האפליקציה.
- שימוש מינימלי ב-API: צריך לבקש ולהשתמש רק בקבוצה הספציפית של ממשקי IWA API שנדרשים כדי להשיג את הפונקציה העיקרית של האפליקציה.
אין טעינה צדדית של קוד דינמי
מודל האבטחה של IWA תלוי ביכולת של האדמינים או של ספק הדפדפן לאמת את כל הלוגיקה שניתנת להרצה. לכן, חבילת ה-IWA צריכה להיות עצמאית. הפלטפורמה אוכפת את המדיניות הזו באמצעות מדיניות אבטחת תוכן (CSP) מחמירה שחוסמת ביצוע מבוסס-מחרוזת כמו eval() ו-new Function():
script-src 'self' 'wasm-unsafe-eval';
require-trusted-types-for 'script';
למרות שמדיניות ה-CSP מאפשרת ל-'wasm-unsafe-eval' לתמוך ב-WebAssembly, אסור לעקוף את מהות גבול האבטחה הזה.
שיטות עבודה שאסורות בתכלית האיסור
- משלוח של מפרשים לקוד מרוחק: אסור לכלול מפרש קוד (לדוגמה, Python או Lua שעברו קומפילציה ל-WASM) כדי להוריד ולהפעיל סקריפטים חיצוניים באמצעות גישה לרשת עם הרשאות מיוחדות, כמו Direct Sockets.
- לוגיקה שנטענת מרחוק: אל תשתמשו ב-service workers כדי להטמיע קוד שנטען מרחוק במקור של ה-IWA.
- קוד לעומת נתונים: מותר להוריד נתונים (כמו JSON), אבל הורדה של קוד שמיועד לפרשנות או להרצה היא הפרה ישירה של המדיניות.
העיקרון של הרשאות מינימליות
תמיד צריך להשתמש ב-API הכי פשוט שיכול לבצע את המשימה. אסור להשתמש בממשקי API ספציפיים של IWA עם הרשאות מיוחדות כקיצור דרך לעקיפת אילוצי האבטחה או ההנחיות למשתמשים של ממשקי API רגילים לאינטרנט. בטבלה הבאה מפורטים תרחישים נפוצים שיעזרו לכם להחליט מתי להשתמש ב-Web APIs רגילים ומתי ביכולות ספציפיות של IWA:
| משימה | שימוש ב-Web API רגיל (מומלץ) | הימנעות משימוש בממשק API של IWA עם הרשאות מיוחדות (מוגבל) |
|---|---|---|
| גישה לכונן קשיח חיצוני | משתמשים ב-File System Access API לקלט/פלט של קבצים רגילים. | אל תשתמשו בUnrestricted WebUSB כדי לגשת לאחסון. |
| אינטראקציה עם כרטיסים חכמים | משתמשים ב-Smart Card API. | אל תשתמשו ב-Unrestricted WebUSB לכרטיסים חכמים. |
| תקשורת עם מכשיר עם יציאה טורית | אם הוא מספיק למכשיר שלכם, השתמשו ב-WebSerial API. | אם WebSerial יכול לבצע את המשימה, עדיף להימנע משימוש בUnrestricted WebUSB. |
| הטמעת תוכן מהימן | משתמשים בערך <iframe> רגיל. |
אל תשתמשו ב-<controlledframe> להטמעה פשוטה, אלא אם נדרשת חסימה לגישה מדומיינים אחרים. |
הנחיות ספציפיות ל-API
ממשקי ה-API של IWA מספקים יכולות עוצמתיות שבדרך כלל מוגבלות בדפדפן. ההנחיה הכללית היא אף פעם לא להשתמש בתכונות המיוחדות האלה באופן שיפתיע את המשתמשים או יפגע באמון שלהם ובנתונים שלהם.
Direct Sockets API
Direct Sockets API מעניק גישה ל-TCP ול-UDP גולמיים, כולל גישה לרשת מקומית ולשידור לקבוצה.
מותר
- תמיכה בפרוטוקולים בהתאמה אישית: חיבור לשרתים מרוחקים שמשתמשים בפרוטוקולים בהתאמה אישית, שאין להם כרגע Web API ברמה גבוהה יותר.
- תחזוקה של שירותי בק-אנד: התחברות לשרת מוגדר מראש עם קידוד קשיח, שמשמש במיוחד לשירותי הבק-אנד של האפליקציה.
- גילוי חומרה חיונית: גישה לרשת המקומית או שימוש בשידור מרובה כתובות כדי לגלות חומרה ספציפית שקשורה לפונקציה של האפליקציה (לדוגמה, אפליקציה לעריכת סרטונים שמאתרת אחסון שמחובר לרשת).
אסור
- הפתעת המשתמש: הטמעת גישה לרשת שלא מוצדקת באופן ברור על ידי הפונקציונליות העיקרית של האפליקציה, כמו עורך טקסט שמתקשר עם מכשירי רשת מקומיים.
- סריקת רשתות באופן שרירותי: ביצוע סריקות רחבות של הרשת המקומית של המשתמש (לדוגמה, סריקת יציאות של 192.168.1.0/24) כדי ליצור פרופיל של המשתמש או לגלות מכשירים לא קשורים.
- טירגוט מכשירים מקומיים: אסור בהחלט לנסות לבצע בדיקה, שינוי הגדרה או התקפה של מכשירים אחרים ברשת המקומית.
Controlled Frame API
רכיב <controlledframe> מאפשר הטמעה ושינוי של תוכן ממקורות שונים, כולל הזרקת סקריפט ושינוי של כותרות.
מותר
- ייעול ממשקי משתמש: הטמעת שירות של צד שלישי והוספת CSS כדי להסתיר רכיבים לא רלוונטיים בממשק המשתמש או כדי לספק חוויה מגובשת יותר.
- תיווך תקשורת מאובטחת: השירות פועל כשומר סף שמקבל בקשות מהדף המוטמע עם
postMessageומחזיר רק נתונים נחוצים שעברו ניקוי, שנשלפו באמצעות ממשקי API עם הרשאות.
אסור
- גניבת פרטי כניסה של משתמשים: הוספת סקריפטים כדי לתעד סיסמאות, קובצי Cookie של סשנים או נתונים רגישים אחרים של משתמשים מהתוכן המוטמע.
- הפרת התנאים וההגבלות של שירותים: שינוי של פלטפורמות מוטמעות באופן שמפר את התנאים וההגבלות שלהן, כמו קליקים אוטומטיים על מודעות או גירוד נתונים לא מורשה.
- העברת גישה עם הרשאות: יצירת מעבר שנותן לתוכן מוטמע ולא מהימן גישה ישירה או לא מבוקרת ל-API של IWA עם הרשאות.
- הטמעה של AI לא מבוקר: ביצוע פעולות בשם משתמש מחובר באמצעות AI ללא מגבלות ספציפיות ושקופות של תרחישי שימוש.
הקלטת מסך ללא הגבלה
מאפשרת צילום מסך ללא ההנחיות החוזרות למתן הרשאה שמופיעות באינטרנט הרגיל.
מותר
- מתן פונקציונליות ליבה: שימוש בצילום מסך כחלק ברור משירות האפליקציה, למשל בתכונות של פגישה וירטואלית או הקלטת הדרכה.
- הגברת המודעות של המשתמשים: חשוב להודיע למשתמשים בצורה ברורה שהקלטה עשויה להתבצע לפני שהם מתחילים להשתמש באפליקציה.
אסור
- הקלטה בהיחבא: צילום המסך של המשתמש ללא ידיעתו והסכמתו המפורשות מראש.
- הפרת תקנות בנושא פרטיות: עיסוק בשיטות הקלטה שמפירות חוקי פרטיות מקומיים או בינלאומיים.
WebUSB ללא הגבלה
WebUSB ללא הגבלה עוקף את רשימת החסימה הרגילה של WebUSB כדי לאפשר אינטראקציה ברמה נמוכה עם מכשירים.
מותר
- תמיכה בחומרה קניינית: אינטראקציה עם חומרה מיוחדת או מדור קודם שאין לה ממשק API באינטרנט ברמה גבוהה, כמו בקרי תעשייה.
עכשיו מותר
- עקיפת ממשקי API ייעודיים: שימוש ב-WebUSB למכשירים שיש להם API ספציפי יותר ומוגבל יותר, כמו כרטיסים חכמים (שימוש ב-Smart Card API) או אחסון חיצוני (שימוש ב-File System Access API).
ניהול החלונות (window.open ו-window.focus)
אפליקציות IWA יכולות ליצור חלונות קופצים וחלונות ממוקדים בלי פעולת המשתמש שנדרשת באינטרנט הרגיל.
מותר
- התראה על השלמת משימה: מיקוד חלון האפליקציה כשמשימת רקע קריטית שהמשתמש יזם, כמו עיבוד סרטון, מסתיימת.
אסור
- הצפת ספאם: הצגת חלונות רבים לא רצויים למשתמש.
- פישינג: פתיחת חלונות שנועדו לחקות תיבות דו-שיח של המערכת או להטעות את המשתמש.
- גניבת המיקוד: שיבוש חוויית המשתמש על ידי גניבת המיקוד מאפליקציות אחרות לאירועים לא קריטיים.
סיכום
ארכיטקטורת האבטחה של אפליקציות אינטרנט מבודדות (IWA) נועדה לתת למפתחים כלים שימושיים תוך שמירה על סביבה מהימנה למשתמשים. אם תפעלו בהתאם להנחיות האלה, תוכלו לוודא שהאפליקציה שלכם תמשיך להיות חלק אחראי מהסביבה העסקית של IWA. הנקודות החשובות ביותר במדריך הזה:
- הקפדה על שקיפות: אופן הפעולה של האפליקציה צריך להיות תמיד בהתאם למטרה המוצהרת שלה. אסור להטמיע פונקציונליות שתפתיע את המשתמש או תפגע בו.
- אכיפת שלמות החבילה: כל הלוגיקה שניתנת להרצה חייבת להיות עצמאית בחבילת ה-IWA כדי לאפשר אימות סטטי. אסור לעקוף את מודל האבטחה באמצעות טעינת קוד דינמי או מפרשים מרוחקים.
- הקפידו על הרשאות מינימליות: תמיד כדאי לבחור את ה-API הכי מוגבל שזמין למשימה נתונה. צריך להשתמש בממשקי API של IWA עם הרשאות מיוחדות רק אם ממשקי API רגילים לא מספיקים לפונקציונליות הליבה של האפליקציה.
- לפעול כגורם מתווך: כשמשתמשים בכלים עוצמתיים כמו
<controlledframe>, ה-IWA צריך לפעול כמתווך מאובטח ולא כפרוקסי שקוף לתוכן לא מהימן.
לפני שמפרסמים את אפליקציית ה-IWA, כדאי לבצע ביקורת סופית של ההטמעה ולשאול את השאלות הבאות:
- האם אני משתמש ב-API הכי פשוט והכי מוגבל שאפשר למשימה הזו?
- האם המשתמש יופתע או ירגיש נבגד ממה שהאפליקציה שלי עושה?
אם התשובה לשאלה הראשונה היא 'לא' או שהתשובה לשאלה השנייה היא 'כן', סביר להניח שהאפליקציה שלך מפירה את מדיניות האבטחה של IWA, והיא עלולה להיות כפופה להסרה.