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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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