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

טיפים קצרים וחדשות למתכנתים

אני לא מאמין ששוב עשיתי את הטעות הזאת...

21/10/2018

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

import React from 'react';

class App extends React.Component {
    render() {
        return
            <div>
                Hello World
            </div>
    }
}

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

import React from 'react';

class App extends React.Component {
    render() {
        return undefined;

            <div>
                Hello World
            </div>
    }
}

הפונקציה הסתיימה בשורת ה return ואף אחד לא הגיע לקוד שמופיע אחרי.

ורק כמה ימים אחרי שהתאוששנו מההלם הזה תלמידה אחרת בקורס Linux שאלה אותי על תוכנית Awk שלא עובדת. הקוד שלה נראה בערך כך:

/^#/
{
    gsub(".", "-");
}

{
    print;
}

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

# List of acceptable shells for chpass(1).
# Ftpd will not allow users to connect who are not using
# one of these shells.

/bin/bash
/bin/csh
/bin/ksh
/bin/sh
/bin/tcsh
/bin/zsh
/usr/local/bin/zsh

התוצאה היתה:

# List of acceptable shells for chpass(1).
------------------------------------------
# Ftpd will not allow users to connect who are not using
--------------------------------------------------------
# one of these shells.
----------------------

---------
--------
--------
-------
---------
--------
------------------

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

/^#/ { print; }

{
  gsub(".", "-");
}

{
  print;
}

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

/^#/ {
  gsub(".", "-");
}

{
  print;
}

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

מודל מנטאלי

18/10/2018

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

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

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

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

לוויתנים

17/10/2018

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

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

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

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

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

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

שלושה טיפים שיעזרו לכם להתחיל עבודה חדשה ברגל ימין

16/10/2018

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

המשך קריאה

קוד (לא) מאובטח

15/10/2018

גירסת 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}`);

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

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

באגים והנדסה חברתית

13/10/2018

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

התופעה המוכרת ביותר היא כנראה כפתורי הלייק הנסתרים: אתם מציגים באתר 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

12/10/2018

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

המשך קריאה