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

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

יש לכם bash גירסא 4? גם אתם יכולים להשתמש ב globstar שיגרום לתבניות הגלוב שלכם לתפוס יותר קבצים. בואו נראה מה זה ואיך מפעילים.

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

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

או ניזכר ב git: אם המודל המנטאלי שלכם אומר שקומיט מייצג את השינויים בין שתי גירסאות יהיה לכם קשה מאוד להבין איך filter-branch או rebase עובדים. רק כשמחליפים מודל מנטאלי ומתיחסים לקומיט בתור "מצב הפרויקט ברגע מסוים בהיסטוריה" כל השאר מתחבר ונהיה הגיוני.

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

יש טכנולוגיות שהן כל כך גדולות שהליכה לאיבוד היא ברירת המחדל בהן. הדוגמאות מהחיים שלי הן: 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 ימים אחורה וזה היה מאוחר מכדי להפסיק.