הבלוג של ינון פרק

יש טכנולוגיות שהן כל כך גדולות שהליכה לאיבוד היא ברירת המחדל בהן. הדוגמאות מהחיים שלי הן: Rails, Angular וכמובן Unix. וככל שטכנולוגיה גדולה כזו חיה יותר שנים כך נוצרות יותר ויותר דרכים "פשוטות" לעשות דברים, דרכים שכמובן רק מגדילות את נפח הפנים של הבעיה שלפנינו.

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

אבל למתכנת שעובד על כזו מערכת זו גישה הרסנית. לאורך זמן אתם לא מנצלים את השנים בעבודה על המערכת כדי לצבור ניסיון רלוונטי ובעוד 4 שנים תמצאו את עצמכם יודעים רק את אותם 20% שעבדו עבורכם באותו מקום. כשתגיעו לראיון עבודה במקום חדש שעובד באנגולר זה יהיה מביך לשני הצדדים.

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

ארבע שנים קדימה והרווחתם מיומנות אמיתית בפריימוורק ואני מקווה שגם נהניתם מהדרך.

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

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

גירסת ES6 של JavaScript הוסיפה יכולת שחיכינו לה המון זמן והיא שיערוך משתנה בתוך מחרוזת. הקוד הבא לדוגמא מדפיס Hello ynon:

name = 'ynon';
console.log(`Hello ${name}`);

מהר מאוד מתכנתים הבינו שאפשר להשתמש בזה כדי לבנות טמפלייטס ל HTML לדוגמא הקוד הבא שפונה ל swapi.co כדי להביא את השם של הדמות הראשית ולהציג אותה על המסך:

$.get('https://swapi.co/api/people/1', luke => {
    $('body').append(`<p>Character 1's name is: ${luke.name}`);
});

וכמו שזה פשוט ככה זה שבור: הרי אם המידע שמגיע מהרשת כולל תגיות HTML או חלילה את התגית script אז הדפדפן של כל אחד מהגולשים יריץ את הסקריפט הזה ויצרנו פירצת XSS בלי להתכוון.

אם אתם משתמשים בטכניקה הזו בקוד שלכם ספריה קטנה בשם common-tags עשויה לעזור. היא כוללת אוסף של Tagged Template Literals שזה פונקציות חלופיות לשיערוך משתנים בתוך מחרוזות. הנה גירסא נוספת להשוואה הכוללת קודם הכנסה לא מאובטחת של משתנה ואחר כך גירסא מאובטחת:

import { safeHtml } from 'common-tags';

const name = 'demo <b>haha</b>';

$('body').append(`<p>Character 1's name is: ${name}`);
$('body').append(safeHtml`<p>Character 1's name is: ${name}`);

והתוצאה בקודפן:

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

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

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

התופעה המוכרת ביותר היא כנראה כפתורי הלייק הנסתרים: אתם מציגים באתר iframe של פייסבוק עם כפתור לייק אבל מעליו שמים כפתור שמשתמשים הרבה יותר ימהרו ללחוץ עליו, לדוגמא פירסומת שהאיקס שסוגר אותה מסתיר מתחתיו כפתור לייק; או לאחרונה עם כל המודעות האלה שדורשות שתסכים לקבל עוגיות אפשר פשוט לשים כפתור לייק מאחורי כפתור ההסכמה לעוגיות. עוד רעיונות ודוגמאות להסתרת כפתורי לייק תוכלו למצוא בקישור:

https://eliteinformatiker.de/2011/08/10/howto-hack-facebook-like-button-with-clickjacking

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

בסיפור אחר נטפליקס נתקלו בבאג שיצר פתח להנדסה חברתית מעניינת. מסתבר שגוגל לא לוקחים יותר מדי ללב את הנקודות בכתובת המייל שלכם לכן הודעות דואר לכתובת ynon@gmail.com ולכתובת yn.o.n@gmail.com יגיעו לאותה התיבה. נטפליקס דווקא כן מתיחסים לנקודות כחלק מהמייל ולכן שני המיילים שהצגתי יוכלו להירשם כשני חשבונות נטפליקס שונים.

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

https://www.theregister.co.uk/2018/04/10/gmailnetflixphishing_vector/

נטפליקס לבד מאובטחים, ג'ימייל לבד מאובטחים, אבל יחד יש פה פוטנציאל לבעיה.

דוגמא נוספת כזאת היתה כש Inti De Ceukelaire שם לב שכל מה שצריך כדי להיכנס לסלאק הארגוני של חברה זה גישה לתיבת מייל עם הדומיין של החברה. זה אולי נשמע קשה עד שאתם נזכרים שהרבה חברות מוכנות לתת לכם כתובת מייל ארגוני אם רק תדעו על איזה כפתור ללחוץ. קחו לדוגמא את המנגנון שמאפשר לפתוח קריאת שירות בתמיכה דרך אימייל: אתם שולחים מייל לכתובת מייל מיוחדת בארגון והמייל הזה מתרגם אוטומטית לקריאת תמיכה בה אפשר לצפות אונליין. הדוגמא הראשונה שהוא זיהה היתה גיטלאב שם לכל פרויקט יש כתובת מייל מיוחדת שמיילים נכנסים אליה יוצרים Issues בפרויקט.

אינטי לקח את כתובת המייל הזו ונרשם איתה לסלאק. הכתובת עם סיומת @gitlab.com ולכן אפשר להירשם איתה לשרת הסלאק הפנימי של גיטלאב. כשסלאק שלחו לשם את קוד האימות כל מה שהיה צריך זה להסתכל ברשימת ה Issues של הפרויקט כדי לקרוא את הקוד ולהתחבר לסלאק הארגוני שלהם.

פרטים נוספים על הסיפור הזה בקישור:

https://medium.com/intigriti/how-i-hacked-hundreds-of-companies-through-their-helpdesk-b7680ddc2d4c

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

ולסיום הסיפור שלדעתי מוביל בסדרי גודל מבחינת המוזרות שלו הוא היכולת של מתכנתים להשפיע על כפתור ה Back בדפדפן. רעיון טכנולוגי נחמד שנועד לאפשר למי שבונה Single Page Web Application לייצר חווית משתמש דומה ליישומים רגילים. דן פטרוביץ החליט לנסות להשתמש לרעה במנגנון ויצר אתר שכפתור "אחורה" שלו מוביל לדף פנימי בתוך האתר שנראה בדיוק כמו דף תוצאות חיפוש של גוגל. בצורה כזו משתמש חושב שהוא יצא מהאתר וחזר לגוגל אבל למעשה עדיין נמצא באתר שלו.

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

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

https://www.smartspate.com/a-way-to-monitor-visitors-to-competitors-sites/

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

שאלה שעלתה היום בקבוצת טלגרם שלנו הזכירה לי כמה אני אוהב את אופרטור קטן מסוגריים עגולים של Bash. מוזמנים להמשיך לקרוא ואזכיר גם לכם.

במקרה הכי טוב ההתלהבות של ההתחלה תספיק לכם ל-3 שבועות. לרובנו היא תספיק לשבועיים. וזה כמעט לא משנה באיזה נושא או כמה התלהבתם ממנו כשהתחלתם.

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

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

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

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

דברים רעים קורים אבל בתוכנה הם הרבה פעמים לא קורים בהפתעה. זוכר את מערכת ההפעלה שלא שידרגת שנתיים? יש האקרים בעולם אבל בינינו אם היית משדרג את התשתיות היה להם הרבה יותר קשה לעבוד.

או הפסקת החשמל האחרונה שהפילה את השרת ומחקה למשתמשים נתונים חשובים. דברים רעים קורים אבל הם קורים יותר לאנשים שלא מחזיקים גיבויים או לאנשים שלא יודעים איך לשחזר את הנתונים מהגיבוי.

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

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

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

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

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

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

המתכנתים הכי טובים שפגשתי לא ידעו יותר נושאים, הם פשוט ידעו ממש טוב את הדברים שהם ידעו. לכן דרך טובה להשתפר היא פשוט ללכת יותר לאט.