בגלל שהאינטרנט בבסיסו הנו פתוח ונרחב, אבטחה/ הגנה היא נושא חשוב.
זה נכון במיוחד בהצגת שפות כמו java ו- JS מכיוון שהן מאפשרות לתוכן בר ביצוע להיות משובץ
בדפים סטטיים אחרים. מאחר וטעינת דף web יכולה לגרום לקוד שרירותי להתבצע במחשב האישי,
דרושים אמצעי זהירות מחמירים להגנה על מנת למנוע מקוד "זדוני" עשית נזק למידע או לחשאיות/פרטיות.
1. Java script ואבטחה
JS אינה בעלת יכולות הגנה אבטחה מפני קוד "זדוני".
למשל, צד הלקוח ב- JS אינו מספק דרך לכתוב או למחוק קבצים או מחיצות במחשב הלקוח. תוכנית JS אינה יכולה למחוק נתוני משתמש או וירוסים מושתלים במערכת המשתמש ללא אובייקט File ופונקציות גישה לקובץ
למשל, צד הלקוח ב- JS אינו מספק דרך לכתוב או למחוק קבצים או מחיצות במחשב הלקוח. תוכנית JS אינה יכולה למחוק נתוני משתמש או וירוסים מושתלים במערכת המשתמש ללא אובייקט File ופונקציות גישה לקובץ
באופן דומה, צד הלקוח ב- JS אינו בעל תכונות של הרשת מכל סוג.
תוכנית JS יכולה להטעין URL ולשלוח טופסי מידע HTML לשרתי web, תסריטי CGI,
וכתובות email, אבל אינה יכולה להקים קשר ישיר עם מחשבים מארחים אחרים ברשת.
זה אומר, למשל, אין אפשרות לשימוש במכונת הלקוח כפלטפורמת מתקפה שממנה יתבצע
ניסיון לפצח סיסמאות של מכונה אחרת.
בעוד שהמחסור המכוון של מאפיינים בצד הלקוח של JS מספק רמה בסיסית
של הגנה מפני המתקפות הגסות יותר, נושאי אבטחה אחרים נשארו.
ישנם נושאי פרטיות חשובים – תוכנית JS חייבת לאסור לייצא מידע על משתמש של דפדפן כאשר מידע זה אמור להיות פרטי.
כאשר גולשים ברשת, אחת מפיסות המידע, שכברירת מחדל, יש הסכמה להעבירן היא הדפדפן שמשתמשים בו.
כחלק סטנדרטי מפרוטוקול HTTP, מחרוזת המזהה את הדפדפן, הגרסא, והספק נשלחת עם כל בקשה לדף web.
מידע זה הוא ציבורי, כמו כתובת ה-IP, למשל.
מידע אחר, בכל אופן, אינו צריך להיות ציבורי: זה כולל כתובת ה- email, שאינה צריכה להשתחרר,
אלא אם כן נבחר לעשות זאת ע"י שליחת הודעת email או אישור הודעת email אוטומטית שתשלח תחת שם המשתמש.
באופן דומה, ההיסטוריה של הדפדפן ותוכן רשימת הסימניות צריכים להישאר פרטיים.
הם מצביעים על תחום ההתעניינות.
זהו מידע ששווקים ישירים ואחרים משלמים הרבה כסף עבורו כך שיוכלו
לכוון למטרה מכירות באופן יותר אפקטיבי.
רוב משתמשי הרשת ירגישו חוסר נוחות עם הידיעה שבכל אתר שיבקרו יכול להתגלות שהם בקרו שם. אפילו בהנחה שלמשתמש אין צורך להסתיר פרטים אלו, יש הרבה סיבות טובות לדאגה בהגנה על הפרטיות.
רוב משתמשי הרשת ירגישו חוסר נוחות עם הידיעה שבכל אתר שיבקרו יכול להתגלות שהם בקרו שם. אפילו בהנחה שלמשתמש אין צורך להסתיר פרטים אלו, יש הרבה סיבות טובות לדאגה בהגנה על הפרטיות.
סיבה אחת היא דאגה מעשית על קבלת דואר "זבל" אלקטרוני וכדומה.
סיבה אחרת היא דאגה מאוד לגיטימית על שמירת סודות.
איננו רוצים שתוכנית JS שנטענה מהאינטרנט ורצה בחלון דפדפן רשת אחד,
תוכל לבחון את התוכן של חלונות דפדפנים אחרים שכוללים עמודים שנטענו מחברת האינטרנט מאחורי ה-firewall.
כאשר דפי web מכילים רק HTML סטטי, N, אינטרנט אקספלורר, ודפדפנים אחרים כבר בעלי יכולת להקים ערוצי תקשורת מוגנת ברשת,
כך שהמידע שמועבר ליעד ובחזרה בין השרת ללקוח נשאר פרטי.
אבל ע"י הפיכה של HTML סטטי לתוכנית דינמית, JS פותחת את הדלת לדפי web לא אתיים אשר גונבים מידע ושולחים אותו חזרה לשרת ה- web.
2. מאפיינים מוגבלים או מיוחסים
JS מטילה הגבלות על מאפיינים בטוחים בהם היא תומכת.
לדוגמא, צד השרת של JS תומך במתודה ( )close עבור האובייקט Window,
אבל הוא מגביל מתודה זו כך שתסריט יכול לסגור רק חלון שנפתח ע"י תסריט מאותו שרת ה-web.
למעשה, תסריט אינו יכול לסגור חלון שהמשתמש פתח , אם הוא מנסה,
מוצגת למשתמש תיבת אזהרה השואלת אם הוא באמת רוצה לסגור את החלון.
ההגבלות אינן חוקים קשים וחזקים, אלא, עדיף לחשוב עליהם כמאפיינים פריבילגיים.
הרשימה הבאה מתארת את הגבלות האבטחה או המאפיינים הפריבילגיים, בצד הלקוח של JS.
עבור כל מאפיין , שם הפריבילגיה רשומה כראוי :
עבור כל מאפיין , שם הפריבילגיה רשומה כראוי :
מערך האלמנטים והתכונות של אובייקט ה- History אינם יכולים להיקרא ללא הפריבלגיה : UniversalBrowseRead.
מערך האלמנטים והתכונות מכיל רשומה של URLs שהדפדפן ביקר בהם לאחרונה, וזהו מידע פרטי.
מערך האלמנטים והתכונות מכיל רשומה של URLs שהדפדפן ביקר בהם לאחרונה, וזהו מידע פרטי.
התכונה value של האוביקט FileUpload אינה יכולה להיקבע ללא הפריבילגיה : UniversalBrowserRead.
אם הפריבלגיה הזו אינה יכולה להיקבע , תסריט ללא פריבילגיה יכול לקבוע אותה לכל שם קובץ רצוי ולגרום לטופס לטעון שוב את התוכן של כל קובץ שמוגדר לשרת ה- web.
אם הפריבלגיה הזו אינה יכולה להיקבע , תסריט ללא פריבילגיה יכול לקבוע אותה לכל שם קובץ רצוי ולגרום לטופס לטעון שוב את התוכן של כל קובץ שמוגדר לשרת ה- web.
תסריט אינו יכול לטעון טופס (submit) לתוך mailto או news : URL ללא הפריבילגיה UniversalSendMail או אישור ברור של המשתמש דרך דיאלוג אישור.
טעינה כזו של קובץ צריכה להכיל את כתובת ה-email של המשתמש, אשר לא צריכה להיות ציבורית ללא רשות המשתמש.
טעינה כזו של קובץ צריכה להכיל את כתובת ה-email של המשתמש, אשר לא צריכה להיות ציבורית ללא רשות המשתמש.
תוכנית JS אינה יכולה לסגור חלון דפדפן ללא אישור המשתמש אלא אם כן היא פתחה את החלון בעצמה או שיש לה את הפריבילגיה: UniversalBrowseWrite.
זה מונע מתסריט "זדוני" מלקרוא ל- ( )self.close על מנת לסגור את חלון הדפדפן של המשתמש, ועל ידי כך לגרום ליציאה מהתוכנית.
זה מונע מתסריט "זדוני" מלקרוא ל- ( )self.close על מנת לסגור את חלון הדפדפן של המשתמש, ועל ידי כך לגרום ליציאה מהתוכנית.
תסריט ללא הפריבילגיה : UniversalBrowserWrite אינו יכול לפתוח חלון שקטן מ-100 פיקסל, או לגרום לחלון לשנות את גודלו לגודל שקטן מ-100 פיקסל לכל צד.
באופן דומה, תסריט כזה ללא פריבליגיות אינו יכול להזיז חלון מהמסך,ליצור חלון שגדול מהמסך, ליצור חלון ללא titlebar.
זה מונע מתסריטים מלפתוח חלונות שהמשתמש אינו יכול לראות או שיכולים בקלות להעלם מהעין.
חלונות כאלו יכולים להכיל תסריטים שממשיכים לרוץ לאחר שהמשתמש חושב שהם סיימו את ריצתם.
באופן דומה, תסריט כזה ללא פריבליגיות אינו יכול להזיז חלון מהמסך,ליצור חלון שגדול מהמסך, ליצור חלון ללא titlebar.
זה מונע מתסריטים מלפתוח חלונות שהמשתמש אינו יכול לראות או שיכולים בקלות להעלם מהעין.
חלונות כאלו יכולים להכיל תסריטים שממשיכים לרוץ לאחר שהמשתמש חושב שהם סיימו את ריצתם.
תסריט אינו יכול להסתיר או להראות את ה- menubar, statusbar, scrollbars, toolbar, location bar, directory bar, או sonal bar
של הדפדפן ללא הפריבילגיה : UniversalBrowserWrite.
זה מונע מהתסריט לעשות שינויים "מטרידים" לעדיפויות המוצגות של המשתמש.
של הדפדפן ללא הפריבילגיה : UniversalBrowserWrite.
זה מונע מהתסריט לעשות שינויים "מטרידים" לעדיפויות המוצגות של המשתמש.
לגרום לחלון להציג about : URL, כמו about: cache, דורש את הפריבילגיה : UniversalBrowserRead.
ה-URLs הללו יכולים לחשוף מידע על המערכת , כמו התוכן של ה-cache של דפדפן.
ה-URLs הללו יכולים לחשוף מידע על המערכת , כמו התוכן של ה-cache של דפדפן.
תסריט אינו יכול לקבוע אף אחת מהתכונות של אובייקט Event ללא הפריבילגיה : UniversalBrowserWrite.
הפריבילגיה : UniversalBrowserWrite דרושה לתסריט על מנת ללכוד ארועים שמתרחשים במסמכים או בשכבות הטעונות ממקורות שונים מהתסריט.
תסריט אינו יכול לקרוא את עדיפויות המשתמש ע"י המתודה : ( )preference ללא הפריבילגיה UniversalPreferenceRead.
( )preference הוא מאפיין חדש של N 4 . זוהי מתודה של האובייקט N.
( )preference הוא מאפיין חדש של N 4 . זוהי מתודה של האובייקט N.
תסריט חייב להיות בעל הפריבילגיה : UniversalPreferenceWrite במטרה להשתמש במתודה preference( ) על מנת לקבוע את עדיפויות המשתמש.
3. מדיניות ה – "same origin"
ישנה הגבלת אבטחה אחת מרחיקת לכת ב-JS.
הגבלה זו ידועה כמדיניות ה-"same origin" :
תסריט יכול לקרוא רק את התכונות של חלונות או מסמכים בעלי אותו מקור (כלומר, שנטענו מאותו מחשב מארח, דרך אותו port, וע"י אותו פרוטוקול) כמו התסריט בעצמו.
תסריט בעל הפריבילגיה : UniversalBrowserRead מורשה לקרוא את התכונות
של חלונות או מסמכים בעלי מקור שונה, ותסריט בעל הפריבילגיה : UniversalBrowserWrite מורשה לכתוב תכונות אלו.
תסריט בעל שתי הפריבילגיות, או בעל הקומבינציה UniversalBrowserAccess, יכול לקרוא ולכתוב את התכונות של חלונות ומסמכים בעלי מקור שונה.
תסריט יכול לקרוא רק את התכונות של חלונות או מסמכים בעלי אותו מקור (כלומר, שנטענו מאותו מחשב מארח, דרך אותו port, וע"י אותו פרוטוקול) כמו התסריט בעצמו.
תסריט בעל הפריבילגיה : UniversalBrowserRead מורשה לקרוא את התכונות
של חלונות או מסמכים בעלי מקור שונה, ותסריט בעל הפריבילגיה : UniversalBrowserWrite מורשה לכתוב תכונות אלו.
תסריט בעל שתי הפריבילגיות, או בעל הקומבינציה UniversalBrowserAccess, יכול לקרוא ולכתוב את התכונות של חלונות ומסמכים בעלי מקור שונה.
מדיניות ה-same origin אינה למעשה מופנית לכל התכונות של כל האובייקטים בחלון ממקור שונה,
אך היא כן מופנית לרבים מהם, ולמעשה מופנית לכל התכונות של אובייקט ה-Document.
לכל המטרות והכוונות, יש להתייחס לכל התכונות המוגדרות מראש של האובייקטים בצד הלקוח
כמחוץ לתחום של התסריטים חסרי הפריבילגיות שבאו ממקורות שונים.
גישה לתכונות המוגדרות ע"י המשתמש אינה מוגבלת בדרך זו. אם דף web רוצה להיפתח לתסריטים ממקורות אחרים,
הוא צריך להעתיק את הערכים של התכונות הרצויות לחדשים,כאלה המוגדרים עפ"י המשתמש, וע"י כך תכונות אלו הינן בלתי מוגבלות.
לדוגמא, דף web יכול לאפשר לדפים אחרים לבחון את קישורי ההיפר טקסט שלו ע"י הקוד הבא :
Document.mylink = document.links;
מדיניות ה-same origin היא מגבלה חזקה מוצדקת, אך הכרחי למנוע מתסריטים "בלתי הגונים" לגנוב מידע.
ללא מגבלה זו, תסריט בלתי הגון בחלון אחד יוכל לרגל אחר התוכן של חלון דפדפן אחר, שעשוי להכיל מידע פרטי.
עדיין, ישנן נסיבות בהן מדיניות זו מגבילה.
היא מציגה בעיות מעשיות של אתרי web גדולים שמשתמשים ביותר משרת אחד.
למשל, תסריט מ- home.netscape.com עלול באופן לגיטימי לרצות לקרוא תכונות של מסמך שנטען מ-developer.netscape.com.
על מנת לתמוך באתרי web גדולים מסוג זה, 1.1 JS מציגה את התכונה domain של אובייקט ה-Document.
כערך ברירת מחדל תכונה זו מכילה את שם המחשב המארח של השרת (hostname) שממנו נטען המסמך.
ניתן לקבוע תכונה זו, אך ורק למחרוזת שהיא סיומת ה- domain החוקי של עצמו.
על כן, אם התכונה domain היא במקור המחרוזת "home.netscape.com", ניתן לשנות אותה למחרוזת : "netscape.com", אבל לא ל : "home.netscape".
על כן, אם התכונה domain היא במקור המחרוזת "home.netscape.com", ניתן לשנות אותה למחרוזת : "netscape.com", אבל לא ל : "home.netscape".
אם שני חלונות כוללים תסריט אשר קובע את ה-domain לאותו ערך, אותה מדיניות ה-same origin תקפה לגבי שני החלונות
וכל אחד מהם יכול לקרוא תכונות של החלון האחר.
4 . תסריטים חתומים (signed) ופריבילגיות
באינטרנט אקספלורר 4, תסריטים הם תמיד unprivileged ויש אפשרות להימלט מהגבלות האבטחה שתוארו בהתחלה .
N 4, בכל אופן, תומך במודל אבטחה שמאפשר לתסריטים דיגיטליים חתומים לדרוש פריבילגיות,
ובהתאם לאישור המשתמש, להעלות בצורה סלקטיבית הגבלות אבטחה שונות.
חתימה דיגיטלית היא התקן של כתב סתרים המאפשר לדעת/ לייצר בביטחון את המקור של פיסת מידע חתומה כגון תוכנית JS.
חתימה דיגיטלית אינה ניתנת לזיוף ומכילה checksum בכתב סתרים עבור הנתון החתום.
כלומר, אם מוצג קובץ של קוד JS אשר נושא את החתימה הדיגיטלית של: "David Flanagan",
ניתן לדעת שישות מסוימת בעלת השם David Flanagan חתמה על הקוד, ויודעים שהקוד לא שונה מאז שהוא חתם עליו.
כל ישות, מנהל או חברה יכולים להוסיף חתימה דיגיטלית לתוכנית JS או לנתון אחר.
ע"י חתימה של תוכנית JS, החותם מכיר בעצמו כמחבר התוכנית, בעל התוכנית או היוצר ולוקח ומקבל על עצמו את האחריות בעבור פעילויות התוכנית.
אם קוד חתום מתנהג "בצורה זדונית", החתימה הדיגיטלית באופן שאינו משתמע לשתי פנים מגלה את הזהות של הצד האחראי.
חתימה דיגיטלית על קוד של JS היא למעשה, ערבות שהקוד החתום לא יתנהג "בצורה זדונית" ויהיה קוד אמין. למרות ערבות זו, אין למעשה דרך חזרה ע"י תיקון חוקי כלשהו, החותם לפחות שם את שמו הטוב על השורה. אם Netscape מתחילה לפזר תוכניות "זדוניות" עם חתימה משותפת, חתימה זו לא תישאר אמינה למשך זמן.
ע"י חתימה של תוכנית JS, החותם מכיר בעצמו כמחבר התוכנית, בעל התוכנית או היוצר ולוקח ומקבל על עצמו את האחריות בעבור פעילויות התוכנית.
אם קוד חתום מתנהג "בצורה זדונית", החתימה הדיגיטלית באופן שאינו משתמע לשתי פנים מגלה את הזהות של הצד האחראי.
חתימה דיגיטלית על קוד של JS היא למעשה, ערבות שהקוד החתום לא יתנהג "בצורה זדונית" ויהיה קוד אמין. למרות ערבות זו, אין למעשה דרך חזרה ע"י תיקון חוקי כלשהו, החותם לפחות שם את שמו הטוב על השורה. אם Netscape מתחילה לפזר תוכניות "זדוניות" עם חתימה משותפת, חתימה זו לא תישאר אמינה למשך זמן.
חתימה דיגיטלית רק מייצגת זהות, היא אינה מייצגת אמינות.
אם מתקינים תוכנית JS אשר מפזרת חתימה דיגיטלית של ישות בעלת שם :Chaos Computer Club או Viruses Unlimited,
יודעים משהו על המקור של התוכנית, אבל אין זה אומר שניתן לבטוח בתוכנית. החלטות אמינות
יכולות לבוא רק ממשתמש הקצה. ע"י יצירת זהות, חתימות דיגיטליות משרתות כחלק חשוב ממדיניות הגנה כוללת, אך הן רק חלק מהפאזל.
התמונה השלמה של ההגנה כוללת הרבה החלטות על מדיניות של המשתמש, שהן הצהרות על אמון.
למשל, אפשרות אחת למדיניות היא: " איני סומך על קוד ה-JS שלי, אלא אם כן הוא כולל את
החתימה הדיגיטלית של Netscape, Oreilly & Associates, או David Flangan".
אמון הוא אינו מתג, on או off, בכל אופן, יכולות להיות רמות שונות ורבות של אמון.
במודל האבטחה של Netscape, אמון מדוד ע"י קבוצת פריבילגיות הנענות/מסכימות לעקרון אחד.
לדוגמא, ישות אחת יכולה להיות מורשת בפריבילגיה :UniversalBrowserWrite, אבל לא בפריבילגיה UniversalSendMail. מדיניות של אבטחה מורכבת מרשימת כל הישויות האמינות וקבוצת הפריבילגיות שכל ישות צריכה לקיים.
לדוגמא, ישות אחת יכולה להיות מורשת בפריבילגיה :UniversalBrowserWrite, אבל לא בפריבילגיה UniversalSendMail. מדיניות של אבטחה מורכבת מרשימת כל הישויות האמינות וקבוצת הפריבילגיות שכל ישות צריכה לקיים.
עיצוב של מדיניות אבטחה כזו יכולה להוות עבודה מרובה.
תיאור של הכל מראש זה לא משהו שניתן לצפות לו ממשתמשים נאיביים של דפדפן.
לכן, מודל האבטחה של Netscape אינו מעניק סתם פריבילגיות לקוד חתום. במקום זאת, הוא דורש מהקוד לבקש את הפריבילגיות הנדרשות לו.
ע"י כך, הדפדפן מסוגל להציג למשתמש ברירה: " תוכנית JS חתומה ע"י David Flanagan ביקשה רשות לשלוח email הנושא את שמך.
האם אתה בוטח ב- David Flanagan מספיק כדי לתת לה את הפריבילגיה הזו ?
האם אתה רוצה לענות לכל קוד עתידי כלשהו שחתום ע"י David Flanagan כך ?"
ברירה זו מוצגת למשתמש ע"י דיאלוג אבטחה .
ע"י הדרישה מתסריטים לבקש את הפריבילגיות שלהם,N 4 מאפשר למשתמש לבנות את מדיניות האבטחה וכל מקרה לגופו.
למשתמש מוצגות בחירות כשצריך, ובעוד שזה יכול להיות קצת מסורבל בפעם הראשונה שתוכנית חתומה רצה,
הדפדפן זוכר את הבחירות של המשתמש, כך שהדיאלוגים מוצגים רק בפעם הראשונה שהתוכנית רצה.
לסיכום, מודל האבטחה של Netscape מתחיל עם קבוצה של פעולות מוגבלות, כמו שליחת email,
בו תסריטים בלתי אמינים אינם מורשים לביצוע. הוא משתמש בחתימה דיגיטלית על מנת ליצור בבטחה את המקור של תסריטים
חתומים ולוודא שהתסריט אינו מושחט או פגום מאחר והוא חתום.
תסריטים חתומים חייבים לבקש ולקבל פריבילגיות לפני שהם יכולים לבצע פעולות מוגבלות.
על מנת לקבל פריבילגיה, N חייב לדעת אם משתמש הקצה בוטח בחותם מספיק על מנת לאפשר את הפריבילגיה.
על מנת לקבוע את רמת האמון, הדפדפן שואל את המשתמש, או "מתייעץ" בבסיס נתונים של מדיניות האבטחה בהחלטות אמון שהמשתמש כבר עשה.
5. חתימת תסריטים
ניתן לחתום על תוכנית JS ע"י תוכנית מ-Netscape הנקראת: signtool .
תוכנית זו זמינה להתקנה מהאתר של Netscape :
http://developer.netscape.com/software/signedobj/jarpack.html
מכיוון שתוכנית JS בדר"כ מורכבת ממספר תסריטי included, תסריטים משובצים, ו- event handlers, חתימה על תוכנית JS היא למעשה עניין של יצירת
חתימה דיגיטלית עבור כל אחד מהחלקים הנפרדים של קוד JS בתוכנית.
כל חלק של קוד חייב להיות חתום או הפונקציות של התוכנית אם הוא אינו חתום.
Signtool מייצרת את כל החתימות הדיגיטליות שדרושות ומאחסנת אותם בקובץ JAR.
פורמט זה הוא נפוץ בתכנות ב- java.
זהו כמו קובץ ZIP עם התוספת של מחיצה metainformation שמכילה מידע כמו תוכן של קובץ דחוס
(archive), ומידע מסיע כמו חתימות דיגיטליות.
כל קוד JS שכלול ע"י התווית <SCRIPT SRC=> ממוקם ב- JAR.
תסריטים משובצים ו- event handlers יכולים באופן אופציונלי להיכלל ב- JAR,
אבל גם נשארים ב- HTML שלהם. בצורה אופינית, רק החתימות הדיגיטליות של חלקי קוד אלו מאוחסנים ב- archive.
הכנת הקבצים לחתימה
לפני שניתן להריץ signtool על מנת לחתום על קוד JS בקובץ HTML, חייבים להכין את קובץ ה- HTML לחתימה.
בקובץ HTML, מגדירים את השם של קובץ ה- archive ע"י התכונה ARCHIVE של התווית <SCRIPT>.
רוב תוכניות JS משתמשות בקובץ archive אחד.
Event handlers של אלמנטים של HTML הם כמו תסריטים משובצים בכך שהם חסרי שם.
ועל מנת ש- event handler יהיה חתום, אלמנט ה- HTML, שהוא חלק ממנו, חייב לקבל תכונת ID (זיהוי) יחידה במינה.
כך גם עבור ישויות של JS.
ישות JS היא קוד JS אשר מופיע כערך בתכונה & {and}, תוחמים.
כל תווית HTML אשר מכילה ישות JS כזו חייבת גם להיות בעלת תכונת ID יחודית.
לבסוף, אין דרך כללית לקשר שם ב- "javascript:URLs" , כך קוד JS שמופיע ב- URLs אינו יכול להיות חתום.
מכיוון שכל קוד JS בתוכנית חייב להיות חתום, לא ניתן להשתמש ב-"javascript:URLs" בתוכניות חתומות.
הדוגמא הבאה מראה תוכנית JS פשוטה אשר מוכנה לחתימה עם התכונות ARCHIVE ו-ID :
הדוגמא הבאה מראה תוכנית JS פשוטה אשר מוכנה לחתימה עם התכונות ARCHIVE ו-ID :
<!-- JAR - מגדירה את שם קובץ ה ARCHIVE - תכונת ה .JAR התוכן שלו ימוקם בקובץ ,include זהו תסריט וגם את שם החתימה הדיגיטלית של קוד זה archive - מגדיר את שם הקוד שבתוך ה - SRC וקובץ ה -- > <SCRIPT ID ="s1"> /* inline זהו תסריט .SCRIPT ARCHIVE הוא במרומז משתמש בתכונה המוגדרת בתווית הראשונה מגדירה את השם שתחתיו תאוחסן החתימה הדיגיטלית עבור קוד זה ID תווית ה */ var history_window; </SCRIPT> <FORM> <!-- ולכן חייבים להיות חתומים JS אשר מכילים קוד event handler שני כפתורים אלו בעלי מגדירה את השמות שתחתם יאוחסנו החתימות הדיגיטליות עבור קוד זה בקובץ ID תכונת ה קודמת ARCHIVE JAR שמוגדר ע"י תכונת SCRIPT חכולה להיות מוגדרת רק עבור תווית ARCHIVE יש לשים לב שתכונת .event handler חייבת להופיע לפני כל SCRIPT לכן תווית -- > <INPUT TYPE=BUTTON VALUE="Show History" ID="s2" onClick="history_window=openHistoryWindow();"> <INPUT TYPE=BUTTON VALUE="Hide History" ID="s3" onClick="history_window.close();"> </FORM>
signing certificate
לפני יצירת חתימה דיגיטלית, חיבים שיהיה מה שידוע כ- "signing certificate".
אישור זה הוא נתון חתום ע"י צד שלישי אמין אשר מאשר שאתה הוא מי שאתה טוען.
ההסבר לצורך באישור זה הוא באמצעות האנלוגיה הבאה: כאשר הולכים לחנות
ומנסים לשלם עבור המצרכים ע"י המחאה בעלת החתימה: "Bill Gates", המוכר לא יקבל את ההמחאה ללא הצגת תעודה מזהה.
על מנת לקבל את האישור, משלמים לחברה המוכרת בשם CA) certificate authority) .
עם הכסף שמשלמים להם, הם מבצעים חקירות, וברגע שהם בטוחים שאתה הוא מי שאתה טוען,
הם מאשרים זאת, ומכינים קובץ קטן על מקבל האישור עם פרטים מזהים, החתום עם החתימה הדיגטלית שלהם.
signtool יוצר מבחן אישור הניתן לשימוש במהלך הפיתוח ובזמן בחינת התוכנית.
מבחן זה אינו מאושר ע"י CA. האישור הוא חתימה עצמית.
על מנת ליצור אישור כזה ששימושי בפיתוח תוכנה יש להשתמש באופציה G עבור signtool.
כמו כן יש להשתמש באופציה d על מנת להגדיר את התיקיה בה יותקן האישור.
במערכות UNIX תיקיה זו היא: ~ /.netscpae.
במערכת WINDOW 95 : c:\Program Files\Netscape\Usres\default\.
יש לשים לב שבגלל ש-signtool מעדכן את ה-key ומשתמשים בבסיס הנתונים של האישור ע"י N, יש לצאת מ-N לפני יצירת המפתח.
כמו כן, מאחר ומפתחות ואישורים הם מוגנים ע"י סיסמאות, חייבים להשתמש בחלון Security Info של N לקבלת סיסמא לפני יצירת מפתח.
יש לבחור ב- Passwords בדיאלוג Security Info על מנת ליצור סיסמא. הדוגמא הבאה מראה יצירת אישור.
הטקסט שהוכנס ע"י המשתמש הוא באותיות מודגשות:
הטקסט שהוכנס ע"י המשתמש הוא באותיות מודגשות:
oxymoron:163 % signtool -G davidflanagan –d ~/. netscape using certificate directory : /home/david/.netscape Enter certificate information. All fields are optional. Acceptable characters are numbers. Letters, spaces, and apostrophes. certificate common name: David flanagan organization: O`Reilly organization unit: state or province: CA country(must be exactly 2 characters): US username: david email address: enter email address Enter Password or Pin for "Communicator Certificate DB":enter password generated public /private key pair certificate request generated certificate has been signed certificate "davidFlanagan" added to database Exported certificate to x509.raw and x509.cacert
חתימה על הקוד
לאחר הכנת קבצי ה-HTML לחתימה ויצירת מבחן אישור, ניתן להשתמש ב- signtool
לייצר קובץ JAR המכיל את החתימה הדיגיטלית הדרושה. על מנת לעשות זאת עליך לפעול על פי השלבים הבאים :
1. יצירת מחיצה ריקה.
2. העתקת קיבצי ה- HTML ו-JS המיועדים לחתימה למחיצה החדשה.
3. קריאה ל- signtool. הגדרה כי אלו הם קבצי HTML ו-JS המיועדים לחתימה ע"י האופציה J.
הגדרת האישור לשימוש עבור החתימה ע"י האופציה k. שימוש בשם המחיצה כארגומנט הסופי ב-command line.
4. לאחר סיום ה- signtool, המחיצה כוללת JAR archive עם השם שהוגדר בתכונת ה-ARCHIVE של התווית <SCRIPT> בקבצי ה- HTML. signtool יוצרת גם מחיצה עם הסיומת arc.
זוהי גירסא לא ארוזה של jar archive בעוד שהיא מספקת דרך קונבנציונלית לבחון את התוכן של ה-archive, מחיצה זו אינה נחוצה וניתן למחוק אותה.
2. העתקת קיבצי ה- HTML ו-JS המיועדים לחתימה למחיצה החדשה.
3. קריאה ל- signtool. הגדרה כי אלו הם קבצי HTML ו-JS המיועדים לחתימה ע"י האופציה J.
הגדרת האישור לשימוש עבור החתימה ע"י האופציה k. שימוש בשם המחיצה כארגומנט הסופי ב-command line.
4. לאחר סיום ה- signtool, המחיצה כוללת JAR archive עם השם שהוגדר בתכונת ה-ARCHIVE של התווית <SCRIPT> בקבצי ה- HTML. signtool יוצרת גם מחיצה עם הסיומת arc.
זוהי גירסא לא ארוזה של jar archive בעוד שהיא מספקת דרך קונבנציונלית לבחון את התוכן של ה-archive, מחיצה זו אינה נחוצה וניתן למחוק אותה.
הדוגמא
הבאה מראה תעתיק של תהליך החתימה במערכת UNIX :
oxymoron:174 % mkdir history oxymoron:175 % cp history.html history.js history/ oxymoron:176 % signtool –j –k davidflanagan history using key "davidflanagan" using certificate directory: /home/david/.netscape Generating inline signatures from HTML files in: history Processing HTML file: history.html (stashing a copy of history.js - > history.arc) entry: history.arc/inlineScripts/s1 entry: history.arc/inlineScripts/s2 entry: history.arc/inlineScripts/s3 signing: history/history.jar Generating history /history.arc/META-INF/manifest.mf file... -- > history.js adding history/history.arc/history.js to history/history.jar... -- > inlineScripts/s1 adding history/history.arc/ inlineScripts/s1 to history/history.jar... -- > inlineScripts/s2 adding history/history.arc/ inlineScripts/s2 to history/history.jar... -- > inlineScripts/s3 adding history/history.arc/ inlineScripts/s3 to history/history.jar... Generating zigbert.sf file... Enter password or Pin for:"communicator Certificate DB": enter password adding history/history.arc/META-INF/manifest.mf to history/history.jar... adding history/history.arc/META-INF/zigbert.sf to history/history.jar... adding history/history.arc/META-INF/ zigbert.rsa to history/history.jar... jarfile "history/history.jar" signed successfully oxymoron:177 % ls history history.arc history.html history.jar history.js
Codebase Principals
חתימת תסריטים יכולה להיות תהליך מסורבל בזמן פיתוח תוכנית.
בגלל שחתימה דיגיטלית כוללת checksum נסתר של המידע החתום, הקוד חייב להיות
חתום מחדש לאחר כל שינוי שעושים בו. דבר שיכול להאט את תהליך הפיתוח וה-debugging.
4 N תומך ב- "codebase principals" כאופציה אלטרנטיבית לתסריטים חתומים.
כברירת מחדל, רק חתימה דיגיטלית או שרת web מאובטח מספיק לייסד ישות, או עקרון, אשר אחראי לתוכנית.
בכל אופן, אם מתאפשר מאפיין ה- codebase principals, N מתייחס לכל codebase כאל עקרון
יחודי ומאפשר להקצות אמון לתוכניות JS המבוסס על מקורן, יותר מאשר על זהות ההגנה של יוצרן.
כך domain של האינטרנט הוא codebase יחודי, וקבצי המערכת המקומיים גם יוצרים codebase.
עם האפשרות של codebase principals, ניתן לייסד מדיניות הגנה מוצהרת, למשל, ברצוננו להעניק את הפריבילגיה UniversalBrowserWrite לקוד JS שמגיע מהשרת www.davidflanagan.com, ויותר מכך, ברצוננו להעניק כל פריבילגיה מבוקשת לקוד JS שנטען דרך file : URL מקבצי מערכת מקומיים.
עם האפשרות של codebase principals, ניתן לייסד מדיניות הגנה מוצהרת, למשל, ברצוננו להעניק את הפריבילגיה UniversalBrowserWrite לקוד JS שמגיע מהשרת www.davidflanagan.com, ויותר מכך, ברצוננו להעניק כל פריבילגיה מבוקשת לקוד JS שנטען דרך file : URL מקבצי מערכת מקומיים.
אמון מוקצה ל- codebase principals כמו לעקרון עם יותר זהות הגנה:
המשתמש נשאל האם להעניק או לשלול פריבילגיה מבוקשת כלשהי.
שימוש ב- codebase principals משחרר מהדרישה לחתום על תסריטים לאחר כל שינוי,
אך מאחר וזה לא בטוח, זוהי לא אופציה שכדאי לאפשר אותה.
הסיבה ש- codebase principals אינם בטוחים היא משום שלא קשה למפצחים מנוסים לרמות את המחשבים המארחים באינטרנט. לא רצוי לבטוח בקוד JS המבוסס על מוצאו בלבד, משום שמקור זה יכול להיות מזויף בקלות.
הסיבה ש- codebase principals אינם בטוחים היא משום שלא קשה למפצחים מנוסים לרמות את המחשבים המארחים באינטרנט. לא רצוי לבטוח בקוד JS המבוסס על מוצאו בלבד, משום שמקור זה יכול להיות מזויף בקלות.
N אינו מאפשר בקלות codebase principals.
למעשה, על מנת להשתמש בהם נדרש מדריך לקובץ העדיפיות של N. המיקום של קובץ זה תלוי במערכת ההפעלה.
ב-WINDOW 95 הקובץ נמצא ב :
ב-WINDOW 95 הקובץ נמצא ב :
C:\Progrm Files\Netscape\Users\default\prefs.js
או :
C:\Progrm Files\Netscape\Users\username\prefs.js
ב-UNIX :
~/.netscape/preferences.js
לאחר מציאת מיקום הקובץ, מאפשרים codebase principals ע"י הוספת שורת קוד JS הבאה לתוכו :
user_pref("signed.applets.codebase_principal_support", true);
6. בקשת פריבילגיות
תסריטים חייבים לבקש כל פריבילגיה שהם צריכים על מנת לבצע פעולות מוגבלות.
מודל הפריבילגיות של N מבוסס על מודל האבטחה של JS ואף משמש במתן פריבילגיות לישומונים של java שרצים ב- N.
כלומר, הפריבלגיות למעשה מנוהלות ונדרשות ע"י java.
על מנת לבקש פריבילגיה, תוכנית JS חייבת להשתמש ב-LiveConnect על מנת לקרוא מתודה של java.
מבקשים פריבילגיה ע"י קריאה למתודה PrivilegeManager של המחלקה netscape.security.PrivilegeManager ב- java.
מעבירים מחרוזת למתודה זו שמגדירה את השם של הפריבילגיה שרוצים לאפשר.
לדוגמא :
netscape.security.PrivilegeManager.EnablePrivilege("UniversalSendMail");
אם המשתמש מעניק את הפריבילגיה, התוכנית יכולה להמשיך לבצע את הפעולות המוגנות אשר תוכניות
שאינן חתומות או אינן אמינות אינן יכולות לבצע.
המתודה ( )enablePrivilege אינה בעלת ערך מוחזר שימושי. אם המשתמש אינו מעניק את הפריבילגיה, המתודה אינה מחזירה ערך false. במקום זאת, היא זורקת exception, שב- N 4 גורם לשגיאת JS "מלוכלכלת".
המתודה ( )enablePrivilege אינה בעלת ערך מוחזר שימושי. אם המשתמש אינו מעניק את הפריבילגיה, המתודה אינה מחזירה ערך false. במקום זאת, היא זורקת exception, שב- N 4 גורם לשגיאת JS "מלוכלכלת".
הפריבילגיות ששימושיות לתוכניות JS הן :
UniversalBrowserRead
מאפשרת לתסריט לקרוא תכונות של החלון ממקורות שונים, לקרוא תכונות ואלמנטים של מערך של אובייקט ה- History,
לחלץ אינפורמציה מ- about מיוחד URLs:
, ולקרוא את התכונה data של האובייקט Event המועבר ל-event handler ondragdrop( ).
, ולקרוא את התכונה data של האובייקט Event המועבר ל-event handler ondragdrop( ).
UniversalBrowserWrite
מאפשרת לתסריט לכתוב תכונות של החלון ממקורות שונים, לקבוע תכונות של האובייקט Event ,
ללכוד ארועים מחלון או מסגרת ממקורות שונים, לסגור חלונות, לפתוח או לשנות גודל קטן מאוד או גדול מאוד של חלונות, ולהזיז חלונות מהמסך.
UniversalBrowserAccess
פריבילגיה זו היא קומבינציה של UniversalBrowserWrite ו- UniversalBrowserRead .
מאפשרת את כל הפעולות שמאפשרות שתי פריבילגיות אלו.
UniversalFileRead
מאפשרת לתסריט לקבוע את התכונה value של האובייקט FileUpload,
על ידי זה, מאפשרת לתסריט להעביר את התוכן של כל קובץ שבקבצי המערכת המקומיים לתסריט CGI בשרת ה- web.
UniversalPreferencesRead
מאפשרת את השימוש במתודה: ( )navigator.preference לחקור את עדיפויות המשתמש.
UniversalPreferencesWrite
מאפשרת את השימוש במתודה: ( )navigator.preference לקבוע את עדיפויות המשתמש.
UniversalSendMail
מאפשרת לתסריט לקרוא למתודה: ( )submit של אובייקט Form ששולח נתוני טופס ל- mailto או ל-news :URL.
הצבת טופס כזה כולל את כתובת ה- email של המשתמש.
משך הזמן של הפריבילגיה
דרך אחת להעלות את האבטחה היא להגביל את הפגיעות של פרצות אבטחה או ע"י הפחתת כמות הקוד שרץ עם פריבילגיות מתרבות.
לכן, פריבילגיה שניתנה ע"י ( )enablePrivilege נשארת רק עד שהפונקציה שאפשרה אותה
חוזרת או עד ששוללים אותה ע"י המתודה: ( )disablePrivilege.
זהו רעיון טוב לחלק את הקוד בעל הפריבילגיות לפונקציות נפרדות, כך הפריבילגיות מתאפשרות רק בזמן שפונקציות אלו רצות.
בחינת היסטורית הדפדפן
הדוגמא הבאה מראה את הקובץ history.js.
היא מכילה מתודה הפותחת חלון חדש ומציגה את היסטורית הגלישה של החלון הנוכחי בתוך החלון החדש.
משום שהיסטורית הדפדפן היא מידע פרטי של המשתמש, הביצוע דורש את הפריבילגיה UniversalBrowserRead, אשר נדרשת ע"י מתודת java enableprivilege( ) :
היא מכילה מתודה הפותחת חלון חדש ומציגה את היסטורית הגלישה של החלון הנוכחי בתוך החלון החדש.
משום שהיסטורית הדפדפן היא מידע פרטי של המשתמש, הביצוע דורש את הפריבילגיה UniversalBrowserRead, אשר נדרשת ע"י מתודת java enableprivilege( ) :
Function openHistoryWindoe()
{
// פתיחת חלון חדש
var w = window.open("","historyWindow","width=500,height=300,menubar,resizable");
var d = w.document;
// בקשת פריבילגיה
netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
// הדפסת היסטורית הדפדפן של החלון הנוכחי לתןך החלון החדש
for(var i=0; i < history; i++)
{
d.write('<A TARGET="new" HREF=" ' +history[i] + ' ">');
d.write(history[i]);
d.writeln('</A>')
}
d.close();
// החזרת החלון החדש
return w;
// הפריבילגיה אינה מאופשרת באופן אוטומטי כאשר פונקציה זו חוזרת
}