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

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

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

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

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

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

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

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

https://www.tocode.co.il/workshops/76

נתראה ינון

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

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

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

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

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

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

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

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

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

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

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

יש לכם רעיונות נוספים? מוזמנים לשתף בתגובות.

שיחה מקרית בקורס היום עזרה לי להבין שבכניסה להייטק (ולפעמים גם די עמוק בפנים) קשה לראות את הערך של תואר אקדמי. הרבה אנשים מרגישים שאפשר להגיע די רחוק גם בלעדיו או שאם את כבר כמה שנים בתעשיה אז אין טעם להתחיל עכשיו תואר. אז בשביל להוכיח לעצמי (ולכם) שבארץ התואר כן חשוב הלכתי לגוגל וחיפשתי פרופילי לינקדאין ישראלים של VP R&D, לא משנה מאיזה חברה. חשבתי שנוכל להעיף מבט יחד מי הם ולמי מהם יש תואר אקדמי. הנה הרשימה שגוגל נתן לי:

1. Karin Moscovici, VP R&D at Riskified - בוגרת מדעי המחשב מהאוניברסיטה העברית.

2. Gil Wasserman, VP R&D at Guesty - בוגר פיזיקה מאוניברסיטת תל אביב.

3. Leon Gendler, VP R&D, Sisense - בוגר מדעי המחשב מאוניברסיטת תל אביב.

4. Ohad Stauber, VP R&D at OSR - מהנדס חומרה בוגר הטכניון.

5. Lior Leiba, VP R&D at Augury - בוגר מדעי המחשב מהטכניון.

6. Avi Etzioni, VP R&D at Planck - בוגר ביואינפורמטיקה מאוניברסיטת תל אביב

7. Shahar Elias, VP R&D at WalkMe - בוגר מדעי המחשב מהמכללה למנהל.

8. Amir Shaked, VP R&D at PerimeterX - בוגר פיזיקה מאוניברסיטת תל אביב

9. Ronny Ahituv, VP of R&D at SkyWatch - בוגר מתמטיקה ומדעי המחשב מהעברית

10. Yaron Gueta, VP R&D at Glassbox Digital - בוגר מדעי המחשב מהאקדמית תל אביב יפו

לא סיננתי ולא חיפשתי במיוחד. אתם יכולים לחזור על החיפוש גוגל שעשיתי. אגב לא הדבקתי לפה אבל בשביל המשחק המשכתי ל-10 תוצאות הבאות ובהן היה רק סמכנ"ל פיתוח אחד עבורו לא הופיע תואר אקדמי בלינקדאין (ניר בצלאל מ Moovit). בכל מקרה וגם אם נתבסס רק על לינקדאין יש לנו 19 מ-20 מנהלי פיתוח בוגרי תואר.

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

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

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

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

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

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

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

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

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

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

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

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

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

אבל העולם לא מוכן לתת לנו את ההזדמנות.

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

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

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

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

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

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