Subresource Integrity

קיבוע סקריפט שנטען על ידי ספריות צד שלישי

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

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

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

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

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

מה זה hash? מדובר באלגוריתם ערבול שיכול לקחת כל קובץ ולייצר ערך ייחודי (או יותר נכון כמעט ייחודי אבל לא נסתבך יותר מדי). בכל פעם שנכניס את הקובץ הזה, אנו מקבל את אותו ערך בדיוק. שינינו תו אחד בקובץ? בום! הערך משתנה. אם יש לכם מק, או לינוקס (או powershell) זה קל לעשות את זה דרך מערכת ההפעלה. נכנסים לשורת הפקודה ומקלידים:

shasum -a 384 FILENAME.js

אנו נקבל מחרוזת טקס. זה תמיד תהיה אותה אחת.

יש גם כלים אונליין לחישוב המחרוזת הזו, כמו למשל: https://www.srihash.org/

את המחרוזת הזו אנו לוקחים וממירים ל-base64 באופן הבא:

shasum -b -a 384 FILENAME.js | awk '{ print $1 }' | xxd -r -p | base64

ואז יוצא לנו מחרוזת טקסט, למשל:

5DgA4+mIrdHxDuEfib4ymsz8aLSlB8sj704DRKPHONExC3v3cO9T+4asEpTk+SqN

את מחרוזת הטקסט הזו אנו מציבים בתגית integrity. למשל:

<script src="https://example.com/example-framework.js"
        integrity="sha384-5DgA4+mIrdHxDuEfib4ymsz8aLSlB8sj704DRKPHONExC3v3cO9T+4asEpTk+SqN"></script>

שימו לב שיש את שם האלגוריתם, במקרה הזה sha384 ואז מקף ורק אז את ה-hash המקודד ל-base64. זהו 🙂

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

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

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

פוסטים נוספים שכדאי לקרוא

פתרונות ומאמרים על פיתוח אינטרנט

יישום של nonce על מנת להגן מפני התקפות injection

בפוסט הקודם הסברתי על hash עם CSP על משאבי inline – שזה נחמד ומעולה אבל פחות ישים בעולם האמיתי שבו בדרך כלל התוכן ה-inline (בין

גלילה לראש העמוד