התוסף עושה בדיוק את מה שהוא מבטיח. הוא חוסם את הפרסומות ב-Twitch, מכריח את הנגן ל-1080p, פותח שידורים שחסומים לפי אזור ואוסף לבד את נקודות הערוץ. בשביל זה כ-30 אלף אנשים התקינו אותו ב-Chrome. הדרך שבה הוא חוסם את הפרסומות היא גם הדרך שבה ה-token של החשבון שלהם יוצא החוצה.

צוות המחקר של Socket פרסם ב-11 בספטמבר ניתוח של התוסף "Twitch Enhanced Viewer | JeetBot", שמופץ גם בחנות של Chrome וגם ב-Firefox Add-ons. לפי הניתוח, שכתב החוקר Kush Pandya, התוסף מעביר את ה-token החי של כל משתמש לשרתי proxy שמפעיל שירות בוטים מסחרי דובר רוסית, וברשומת החנות מופיעים כ-30 אלף משתמשים ב-Chrome ועוד 552 ב-Firefox. שתי הרשומות היו פעילות ביום הפרסום. בהמשך נראה למה תוסף שחוסם פרסומות חייב לגעת בתעבורה המאומתת שלכם, מה בדיוק נשלח בדרך, ולמה דווקא עשרה ערוצים פטורים מזה.

למה חסימת פרסומות ב-Twitch דורשת שרת של מישהו אחר

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

וכאן נולדת הבעיה: הבקשה הזאת נושאת את פרטי האימות של המשתמש. "כדי לספק וידאו נקי מפרסומות ופתוח מבחינה אזורית, התוסף מנתב את בקשות ה-playlist של Twitch דרך שרתי proxy בשליטת המפעיל. ה-token של המשתמש נוסע יחד עם ההפניה הזאת", כתבו החוקרים.

ההרשאות שהתוסף מבקש בהתקנה תואמות את זה בדיוק. הוא מבקש גישה ל-gql.twitch.tv, ל-usher.ttvnw.net ול-id.twitch.tv, שלושת המקומות שדרכם עוברות הבקשות המאומתות של המשתמש.

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

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

"token של session ב-Twitch הוא bearer credential: מי שמחזיק בו יכול לפעול בחשבון בלי הסיסמה ובלי גורם אימות שני, כולל קריאה ושליחה של הודעות פרטיות, כתיבה בצ'אט ושימוש בנקודות הערוץ", כתבו החוקרים.

לפי הניתוח, ה-content script של התוסף קורא את כותרת ה-Authorization מלקוח הווב של Twitch ומעביר אותה, יחד עם מזהה המכשיר, דרך ערוץ ההודעות הפנימי של התוסף אל ה-background worker. שם מוסרת הקידומת כדי להשאיר את ה-token הגולמי. אחרי זה בא שלב שמסגיר כוונה: ה-worker שולח את ה-token לשירות האימות של Twitch עצמה, כדי לוודא שזה token תקף ברמת החשבון ולא משהו מצומצם יותר.

ההעברה עצמה לא נעשית בבקשת רשת נפרדת שאפשר לראות בקלות ב-DevTools. היא רוכבת על מנגנון ההפניה של הדפדפן. ב-Firefox זה נעשה דרך מאזין חוסם ב-webRequest.onBeforeRequest, וב-Chrome דרך כלל declarativeNetRequest שמבצע החלפת מחרוזת בכתובת. כשהבקשה ל-usher.ttvnw.net מופנית אל ה-proxy, מתווסף לכתובת פרמטר בשם auth ובתוכו ה-token עצמו.

המשמעות היא שה-token לא יושב בגוף הבקשה אלא בכתובת. "מכיוון שה-token ממוקם ב-query string של הכתובת, הוא נכתב כטקסט גלוי ביומני הבקשות של שרת ה-proxy", כתבו החוקרים. כלומר הוא לא רק עובר דרך השרת, הוא נשאר שם בקובץ לוג.

היעד שמוגדר כברירת מחדל הוא enhanced[.]jeetbot[.]cc, ולצדו יש כתובות proxy נוספות. הקטלוג שמחליט לאיזה מהן ללכת נשלף מ-API של המפעיל, כך שהצד השני יכול לשנות בזמן אמת לאן ייצאו ה-token-ים.

עשרה ערוצים שמקבלים יחס אחר

עד כאן איך ה-token יוצא. הפרט המעניין יותר הוא מתי הוא לא יוצא.

בקוד של ה-background worker יש רשימה קבועה של עשרה ערוצים שעבורם ה-token נחתך מההפניה: pch3lk1n, fasoollka, flamie, dosia, fander ועוד חמישה. החוקרים מציינים שאלה ערוצים דוברי רוסית, ושכמה מהשמות הם דמויות מוכרות בסצנת Counter-Strike. בכל ערוץ אחר ה-token מועבר בלי תנאי.

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

הגרסאות הישנות מספרות מה קורה בצד השני

מה קורה ל-token אחרי שהוא מגיע לשרת לא נראה מבחוץ. הגרסאות הקודמות של התוסף, לעומת זאת, משאירות רמזים. בגרסה 4.8, שיצאה ב-8 בינואר 2026, ההעברה לא רכבה על הפניה בכלל: הקוד שלח את ה-token בבקשת POST ייעודית לנתיב set-token בשרת של המפעיל, עם שני שרתי גיבוי על תשתית deno. סביב הקוד הזה יש לוגיקה של השהיה בת חמש שניות ושל מניעת שליחה חוזרת של אותו token, עם הערות בקוד ברוסית שמסבירות בדיוק את זה.

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

היסטוריית הגרסאות ב-Firefox עושה קפיצה חדה. מגרסה 7.2.6 ב-25 באפריל 2026 ישר לגרסה 85.2.2 ב-20 במאי, והגרסה החדשה היא זו שהחליפה את בקשת ה-POST הגלויה בהעברה השקטה שרוכבת על ההפניה. בזמן הפרסום הגרסה החיה בחנות הייתה 85.6.1.

מי מפעיל את זה, ולמה זה עבר בשתי החנויות

JeetBot הוא שירות בוטים מסחרי דובר רוסית ל-Twitch, ל-Kick ול-VK-Live. התוסף מפורסם בשתי החנויות תחת הכינוי HISHIMIRO, ובתחתית האתר של השירות מופיע שם מלא, Popov Aleksandr Alekseevich. השם הזה מגיע מהאתר של המפעיל עצמו, ולא מגורם חיצוני שאימת אותו. התשתית שמארחת את הדומיינים מפוזרת בין ספק אחסון גרמני לספק ענן נוסף.

מה שכתוב בחנות הוא סיפור אחר. בהצהרת בטיחות הנתונים ב-Chrome Web Store נכתב שהתוסף לא יאסוף ולא ישתמש בנתוני המשתמש, ושהנתונים אינם נמכרים לצד שלישי. מדיניות הפרטיות באתר, שנושאת תאריך 25 ביוני 2025, אומרת שהתוסף לא אוסף, לא שומר ולא מעבד שום נתון של משתמש, ואינה מזכירה העברה של token-ים לשום מקום. לפי Socket, ההעברה בפועל סותרת את שלוש ההצהרות האלה.

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

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

מה זה אומר בפועל

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

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