אני חושב שכל מי שמתעסק לפחות כמה חודשים בעניין של אחסון אתרים (בין אם אתם מתכנתים, אנשי SYSTEM או בוני אתרים ב-Wordpress),

נתקל פה ושם בבקשה "מאיימת" של הוראות ההתקנה לתת הרשאות 777 לתיקיה מסויימת על מנת לתת לה הרשאות כתיבה (בהתקנת פלאגינים, כתיבת לוגים וכו').

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

נחזור מעט אחורה..

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

Linux מחלקת את הרשאות הקבצים ל-3: Owner, group, other (משם מגיעות בעצם 3 הספרות, לדוגמא: 777)
בדוגמא זו, המשמעות היא שעבור ה-Owner נתנו הרשאת 7, וכך גם עבור ההרשאות עבור ה-Group וה-Other.

משמעות החלוקה אומרת בעצם "למי לתת הרשאות"? כאשר החלוקה עובדת כלדקמן:

• Owner: ה"בעלים" של הקובץ, לרוב גם המשתמש שיצר אותו (למרות שבפועל ניתן ליצור קובץ עם משתמש X ולשנות את ההרשאות שלו מאוחר יותר לבעלות משתמש Y) – לרוב, למשתמש זה יהיו הרשאות מלאות לקובץ.
• Group: ה"קבוצה" – כלומר, אפשרות זו נותנת לנו את האופציה לתת למספר משתמשים שבתוך קבוצה מסויימת הרשאות לקובץ (לדוגמא: אם אנחנו רוצים לתת הרשאות גם למשתמש yossi וגם למשתמש danny, מכיוון שאנחנו לא יכולים לקבוע 2 "בעלים" לאותו הקובץ – אנחנו פשוט נכניס אותם לאותה הקבוצה).
• Other: כל משתמש אחר שלא תואר בקבוצות למעלה (כלומר, הוא לא הבעלים או בקבוצה שהוגדרה).

מה אומרות הספרות?

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

• 1 : ניתן לבצע פעולת Execute לקובץ / תיקיה
• 2: ניתן לבצע פעולת Write לקובץ / תיקיה
• 4 : ניתן לבצע פעולת Read מהקובץ / מהתיקיה

עכשיו רק נשאר לחבר הכול – כאשר אנחנו נותנים הרשאה של 7, אנחנו בעצם מאפשרים Execute (כלומר 1) + Write (כלומר 2) + Read (כלומר 4), סה"כ 7.

כלומר, אם נתנו לתיקיה / קובץ ספציפי הרשאות של 777, בעצם נתנו הרשאה של 7 עבור כל אחת מהקבוצות שציינו מעלה (owner, group, other).

במילים אחרות, אנחנו מאפשרים לכל אחד על השרת לבצע כתיבה לקובץ/תיקיה שאיפשרנו לה את ההרשאות הללו.

רגע רגע רגע, הרגע אמרת שכל אחד יכול לבצע שינוי על הקובץ????

כן, קראתם נכון.

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

שימו לב, מקור הבעיה הוא לא ב-7 הראשון (Owner), אלה בשני (Group) ובשלישי (Other).

למה זה קורה? האם זה באמת סיכון אבטחה?

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

אז לפני הכול, צריך רגע לעצור ולחשוב – איך php רץ בעצם? הרי כאשר אנחנו מעלים קובץ php לשרת, אנחנו לא ניגשים ל-php ישירות אלה ניגשים לשרת ה-web שלנו (apache / nginx / iis וכו'), במילים אחרות, ישנו "מתווך" בינך לבין ה-php – מה שאומר, שבסופו של דבר מי שניגש לאפליציה הוא ה"מתווך".

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

php-cli / dso

php-cli (או dso, אם נתקלתם בשם בממשק הניהול של Cpanel) היא אחת מ-2 תצורות הרצה בסיסיות של php.

בתצורת php-cli, ה-php רץ כמודול של ה-apache (ה-web server שלכם), מכיוון שמנגנון ה-Apache רץ באמצעות משתמש בודד ומשותף לכלל האתרים בשרת (ברוב המקרים, משתמש בשם apache), הוא בפועל מבצע את כלל הפעולות באמצעות משתמש זה (אם מדובר בקריאה לקבצים או כתיבה לתיקיות).

נחזור לנושא ההרשאות:

קבצי האתר שלכם לרוב מועלים באמצעות משתמש ה-FTP שלכם (שלרוב, לא יהיה המשתמש apache), וכברירת מחדל מועלים בהרשאות 644 (לקבצים) ו-755 (לתיקיות).
מכיוון שאמרנו שה-webserver רץ באמצעות משתמש המשותף לכל האתרים בשרת (apache), אתם בעצם חייבים לאפשר למשתמש הרשאות קריאה (לפחות) עבור המשתמש Apache.
הדבר בא לביטוי באופן ברור בהגדרות ברירת המחדל שציינו למעלה (בהרשאות 644, ה-4 האחרון הוא בעצם read עבור הקבוצה other).

עד כאן הכול בסדר – ניתן לגלוש לאתר (מכיוון שהמשתמש apache יכול לבצע read) אך עדין לא דיברנו שום דבר על write – כאן גם מתחילה ה"בעיה".

על מנת לאפשר לגולש באתר לכתוב קבצים, עלינו לתת הרשאות write למשתמש apache, מכיוון שהוא לא ה-owner של הקובץ (וסביר להניח שגם אינו נמצא ב-group), יש לתת הרשאות כתיבה ל-other, ולהזכירכם – other = כלל המשתמשים בשרת.

עד עכשיו, לא שברתי מוסכמות.. php-cli = מסוכן!

php-cgi / php-fpm

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

כלומר, ישנו "שירות" בשם apache שבכל מקרה שאתם פונים לעמוד בסיומת של php "מבין" שעליו לפנות לשירות נפרד בשם "php", להעביר עליו את המידע (הקוד שאתם מריצים) ולקבל "תשובה".

הייתרון בתצורה זו, היא שה-Apache רץ באמצעות משתמש מסויים (לרוב apache, בדיוק כמו ב-php-cli) אבל ה-php עצמו רץ כל פעם באמצעות המשתמש שמריץ אותו (וזאת מכיוון שבניגוד ל-apache, הוא לא צריך לעבוד כל הזמן, אלה עובד "on demand" בכל פעם שנדרש).

אם ה-php רץ כל פעם באמצעות המשתמש שצריך להריץ אותו (ולא באמצעות משתמש מרכזי) – סימן שמבחינת הרשאות אנחנו בסדר, לא?
בערך, אם נסתכל על מפת ההרשאות – ב-php-cgi, על מנת לכתוב בתיקיה אנו נזדקק לתת הרשאות כתיבה אך ורק ל-owner, ולא ל-other.

אז מה הפאנץ'?

הפאנץ' הוא בעיקר בנקודה הסופית – מבחינת אבטחת מידע, בהינתן מצב שגורמים נוספים (עליהם אדבר במאמרים נפרדים) בוצעו, php-cli ו-php-cgi זהים (למרות ההרשאות השונות שיש לתת לקבצים / תיקיות).

איך זה יכול להיות?

בואו נסתכל על סכמות הרצת ה-php בכל אחד מהמערכות:

לכאורה דומה, נכון?

הפאנץ' הוא שבסופו של דבר, ב-2 המקרים, מי שמבצע את הפעולה היא האפליקציה של המשתמש.

כלומר, למשתמש הניגש מבחוץ זה לא ממש משנה, הוא עובד מול השרת (וב-2 המקרים, הוא יוכל לקבל את אותו התשובה מה-php, וב-2 המקרים, אם ירצה – הוא יוכל לבצע write לשרת).

כלומר 2, בסופו של דבר, אם האפליקציה פריצה – התוקף יצליח לכתוב קבצים באותה מידה לשרת העובד עם php-cgi (ומחזיק בהרשאות "חזקות" של 700) או לשרת העובד עם php-cli (המחזיק בהרשאות "חלשות" של 777).

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

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

ולכן לא ניתן לסיים את הקריאה על הנושא במאמר הזה, יש 2 מאמרי המשך מאוד חשובים:
1. מאמר המדבר על open_basedir (והחשיבות שלו בשרת)
2. מאמר המבצע השוואה בין שימוש ב-Php.ini ל-htaccess