טוב אחרי הדיון הקצר עם tnadav1 בנושא באשכול דיון:הדרך הנכונה לסינון SQL INJ וXSS והתנגשות עם מקרה ספציפי שצורך ביטול סינון החלטתי לקרוא קצת בנושא, למרות שהתעסקתי עם זה בעבר ובימינו אלה תוקנו כמה בעיות שהיו בעבר.
אז במהלך החיפוש לסיבה אמיתית למה לא להשתמש ב $_REQUEST, הגעתי לכתבה די מעניינת - אולי לא כל כך קריטית מבחינת אבטחה, אבל כולנו מחפשים בתור מתכנתים להיות פרפקציוניסטים...
הבעיה לא נובעת מעצם זה שהמשתנה $_REQUEST מכיל את הנתונים של $_POST ו-$_GET ביחד, אלא מעצם העובדה שהוא מכיל גם את הנתונים של $_COOKIE.
אין שום סיכון עם זה שקראקר ייצור עוגיות(COOKIES) משלו וינסה לדמות משתנה של $_POST (כאמור שוב, אם הגדרת עוגייה בשם hi הערך שלה יכנס אל $_COOKIE['hi'] אך גם אל $_REQUEST['hi'] - ובדיוק באותה צורה יראו גם משתנים ששלחת בPOST וGET) אך הסיכון נובע מ-Cookie Injection שבוצע על הדפדפן של המשתמש דרך אתר\תוכנה אחרים.
גם אז הסיכון לפגיעה באתר שלך הוא ממש ממש נמוך, אך יכול לפגוע ו\או לעצבן את המשתמש באתר שלך, שפתאום מתנתק מהאתר כי יש לו עוגייה בשם action עם הערך logout והאתר שלך מפרש את זה כאילו הוא ניסה להתנתק מהאתר...

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

מקור:
PHP 5.3 and Delayed Cross Site Request Forgeries/Hijacking

אני לצורך נוחות שילבתי את GET וPOST אבל בכל מקום שאני צריך שליחת POST אני בודקת האם התבצעה שליחת POST לדף...

איתי סלע,
פיתוח מערכות תוכנה ואינטרנט.

ציטוט:

במקור נכתב על ידי itaysela אני לצורך נוחות שילבתי את GET וPOST אבל בכל מקום שאני צריך שליחת POST אני בודקת האם התבצעה שליחת POST לדף...

אם שילבת אותם בלי קשר ל$_REQUEST זה בסדר
אבל הסיכון נובע משימוש ב$_REQUEST ו Cookie Injections...

תודה

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

ציטוט:

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

נכון אבל במצב שלמשל אני גם רוצה להשתמש ב www.example.com/?id=5 וגם להוסיף hidden input עם הערך של id למקרה שהשתמשו ב submit, אז אני צריך לשבור את הראש מאיפה הגיע id... או פשוט אם השתמשו ב submit לקבוע את הערך שלו מ$_POST ואחרת מ$_GET...
זה הולך לכער את הקוד קצת

מה פתאום!

פשוט שים את ה-id במחרוזת שאילתת ה-URL, כך:

קוד PHP:

 echo '<form action="http://www.domain.com/index.php?id=5" method="POST">'; 


עכשיו אני רוצה רק לומר שהכתבה הזו שהבאת הצביעה על רעיון מעולה ומאוד פשוט:

ציטוט:

This has been considered bad practice for a while, because it is actually a violation of the idea behind GET and POST requests: GET is meant to retrieve data, POST is meant to manipulate data.

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

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

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

אתן דוגמא כיצד ניתן להשתמש בפונקציית סינון פשוטה לשימוש:

קוד PHP:

 /**
* Usage examples
*/

// Escape all the $_POST members that have the following keys: 'name', 'about' and 'description'.
$input = $my_object->escape(array('name', 'about', 'description'));

// Escape unique/irregular parameters
$other_input = $my_object->clean_HTML_tags_etc($_GET['uncommon_get_member']);

/**
*  the escape() method... 
*
* @param $elements - The elements to be escaped/cleaned/whatever...
*
* @return void (nothing...)
*/

class yay
{
 // ...
    public function escape(array $elements)
    {
        $input = array();

        foreach($elements as $key)
            $input[$key] = $this->clean_HTML_tags_etc($_POST[$key]);

        return $input;
    }

} 


בצורה הנ"ל, כאשר יכניסו את הנתונים לשאילתות באמצעות המשתנה $input, הסיכוי שבעתיד מישהו יכניס מידע שלא סונן הוא קטן מאוד.

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

ציטוט:

במקור נכתב על ידי dorM מה פתאום! פשוט שים את ה-id במחרוזת שאילתת ה-URL, כך: קוד PHP:  echo '<form action="http://www.domain.com/index.php?id=5" method="POST">';

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

ציטוט:

במקור נכתב על ידי dorM עכשיו אני רוצה רק לומר שהכתבה הזו שהבאת הצביעה על רעיון מעולה ומאוד פשוט: כבר קראתי את הדבר הזה לפני כן, אבל אני חושב שלא הטמעתי את זה כל כך. הקוד מ-GET בדר"כ אינו מצריך סינון, למעט מקרים ספציפיים, ולכן את ה-GET בכלל לא נדרש לסנן מלכתחילה או לדאוג בנוגע אליו. בנוגע ל-cookie, הוא מכיל, ולדעתי אמור אך ורק להכיל, את המידע ששייך ל-session. זה אמור להיות רק session id שהיא מחרוזת מוצפנת, ויכול להיות גם member id ו- member password שגם זה מחרוזת מוצפנת. לכל אלו יש מבנה קבוע שאינו מצריך סינון, ולכן גם את ה-cookie לא צריך לסנן. לכן נשאר רק את ה-POST שמצריך סינון. כאשר יידרש לקחת מידע ממקום מסויים, פשוט יש לסנן את המחרוזות שהן מיועדות להיות מחרוזות, ולא מחרוזות שבסוף נהפוך אותם ל- int, לדוגמא.

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

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

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

קוד PHP:

<?php

foreach($elements as $key)

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

קוד PHP:

<?php

if(!get_magic_quotes_gpc())
{
    function addslashes_array($array)
    {
        return is_array($array) ? array_map('addslashes_array', $array) : addslashes($array);
    }

    $_POST = addslashes_array($_POST);
}

ציטוט:

בתחביר הבא המשתנה key מקבל את ערך האיבר "הנוכחי" שבמשתנה elements, ולא את ערך המפתח/אינדקס.

כן, הוא צריך לקבל את ערך האיבר הנוכחי כיוון שביצעתי את ההכנסה בצורה הבאה:

קוד PHP:

 $input = $my_object->escape(array('name', 'about', 'description')); 


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

ציטוט:

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

נכון, שכחתי את המקרה הזה...תודה

ציטוט:

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

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

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

כמו כן, אתה גם לא יודע מה יהיה בעתיד, על איזה עוד טכניקות יחשבו. לכן, אם אני יודע שערך מסויים שאני מקבל אמור להיות מספר שלם בין מינוס 5 לפלוס 18, אז אני:
א) אעשה אליו cast ל int (או אשתמש ב intval)
ב) אבדוק עם if שהוא בין הערכים שאני מצפה להם, ואם לא, die(). לא איכפת לי שתהיה שגיאה כשמתקבל פרמטר שלא אמור להתקבל מקוד שאני תכננתי. אני יודע מה אני אמור לקבל, ואני אומר את זה למשתמש, ואם המשתמש מנסה להתחכם - את ההתחכמויות אפשר לשמור למקום אחר. את בדיקת הערכים בטופס (אם המקור הוא טופס) צריך לעשות ברמת קליינט, לפני שזה נשלח לשרת. אם זה נשלח בכל זאת, זה אומר שהקליינט "לא כל כך צדיק". שיקבל שגיאה.

נמאס לכם לזכור סיסמאות? לחצו כאן!

ציטוט:

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

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

ציטוט:

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

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

ציטוט:

כמו כן, אתה גם לא יודע מה יהיה בעתיד, על איזה עוד טכניקות יחשבו. לכן, אם אני יודע שערך מסויים שאני מקבל אמור להיות מספר שלם בין מינוס 5 לפלוס 18, אז אני: א) אעשה אליו cast ל int (או אשתמש ב intval) ב) אבדוק עם if שהוא בין הערכים שאני מצפה להם, ואם לא, die(). לא איכפת לי שתהיה שגיאה כשמתקבל פרמטר שלא אמור להתקבל מקוד שאני תכננתי. אני יודע מה אני אמור לקבל, ואני אומר את זה למשתמש, ואם המשתמש מנסה להתחכם - את ההתחכמויות אפשר לשמור למקום אחר. את בדיקת הערכים בטופס (אם המקור הוא טופס) צריך לעשות ברמת קליינט, לפני שזה נשלח לשרת. אם זה נשלח בכל זאת, זה אומר שהקליינט "לא כל כך צדיק". שיקבל שגיאה.

א) מסכים, במקום להריץ פונקציות על מחרוזת בתהליך סינון הקלט, יש קלטים שצריך פשוט להפוך אותם ל-int/float.
ב) למה die? אולי למשתמש יש בעיה שהתקבל ערך כזה ולא אחר?
יכול להיות שיש קלטים שאתה לא יכול לבדוק אותם לפני כן (בלי AJAX). אם המשתמש בתמימות הכניס user name או password עם טעות?
רוב המשתמשים גם לא כ"כ מבינים במחשבים...

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

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

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

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

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

לגבי ב' - משום שאין שום סיבה שהמשתמש יעשה submit לדף ויקבל לאחר מכן שגיאה, כשאפשר לבדוק את זה במסך ההכנסה (אם ב JS ואם ב AJAX אם מדובר בנתון שחייב להיות חח"ע בשרת, ורוצים לוודא שהוא לא קיים כבר). חוץ מזה, שה die() שאמרתי הוא רק כשמתקבל קלט בלתי מתקבל על הדעת. כלומר, ה UI מאפשר למשתמש להכניס מספר בין מינוס 5 לפלוס 18, ואיכשהוא, אל הסקריפט שלנו, מגיע המספר 52. זה יכול לומר רק דבר אחד: או שהמשתמש בא להזיק, או שיש לנו באג ב UI שאנחנו צריכים לתקן (ונתקן), או שלמשתמש יש משהו שמשבש את פעולת המחשב שלו. במקרה הזה, הודעה אדומה ויפה שמזהירה על שליחת נתונים משובשים דווקא עדיפה בעיני.

אגב, פונקציות טיפול כלליות בקלט זה לא תמיד טוב (או אולי אפילו תמיד לא טוב?). יש מקרים שאתה צריך להמיר קלט כדי להעביר אותו לשכבת תצוגה (ואז צריך htmlentities שעובד עם ה charset הנכון של דף הפלט שלנו), יש מקרים שצריך להמיר אותו כדי לפתוח קובץ ממערכת הקבצים או ממערכת מרוחקת, יש מקרים שצריך להמיר אותו כדי לשלוח אותו ל DB, יש מקרים שצריך לתת אותו כפרמטרים לשורת פקודה (escapeshellargs) - ובכל אחד מהמקרים - זו המרה שונה, שתגרום לתוצאות ממש לא רצויות במקרה ומשתמשים בה עבור מידע שמיועד לסוג אחר של שימוש.

נמאס לכם לזכור סיסמאות? לחצו כאן!

ציטוט:

אגב, פונקציות טיפול כלליות בקלט זה לא תמיד טוב (או אולי אפילו תמיד לא טוב?). יש מקרים שאתה צריך להמיר קלט כדי להעביר אותו לשכבת תצוגה (ואז צריך htmlentities שעובד עם ה charset הנכון של דף הפלט שלנו), יש מקרים שצריך להמיר אותו כדי לפתוח קובץ ממערכת הקבצים או ממערכת מרוחקת, יש מקרים שצריך להמיר אותו כדי לשלוח אותו ל DB, יש מקרים שצריך לתת אותו כפרמטרים לשורת פקודה (escapeshellargs) - ובכל אחד מהמקרים - זו המרה שונה, שתגרום לתוצאות ממש לא רצויות במקרה ומשתמשים בה עבור מידע שמיועד לסוג אחר של שימוש.

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

כמו שאמרתי, יש סיבה להפרדה בין GET ל-POST...

שני ערכי id הם בעיה.. ואחד ידרוס את השני..(מי ידרוס את מי זה כבר תלוי מה הוגדר)

עד כמה שאני מבין, לפי ההסבר שלך, הבעייה היא כשמשתמשים ב REQUEST_$ במקום ב COOKIE_$

אבל הדיבור היה על שילוב המידע מ GET ו POST ללא קשר למתודת השליחה - שתוכל לשנות אותה כרצונך, והמידע יהיה זמין בכל מקרה.

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

ציטוט:

במקור נכתב על ידי שימי עד כמה שאני מבין, לפי ההסבר שלך, הבעייה היא כשמשתמשים ב REQUEST_$ במקום ב COOKIE_$ אבל הדיבור היה על שילוב המידע מ GET ו POST ללא קשר למתודת השליחה - שתוכל לשנות אותה כרצונך, והמידע יהיה זמין בכל מקרה. אם אתה טוען שאפשר לעשות הזרקת עוגיות כשבקוד אין התייחסות לעוגיות דרך REQUEST_$, אז אני ממש לא הבנתי איך, ואשמח אם תוכל להסביר. אפשר להזריק ערכים ל GET/POST דרך עוגיות, אבל זו לא בעיית אבטחה per-se. אתה צריך להניח מראש שהמידע שמתקבל שם לא בהכרח מקובל עלייך - ולפעול בהתאם. זה לא חייב להיות מניעת שירות לגולש, אתה יכול פשוט להתעלם מהערך, כאילו לא קיבלת אותו, ועדיין להשתמש ב REQUEST_$.

אני הבנתי את זה מהכתבה שהבאתי, וזה קורה בצורה הבאה: (ואפילו יכול לקרות באתר שלי, בינתיים לפחות)
יש לך משתנה בשם page. לא משנה איך הוא מתקבל, GET\POST
בקוד שלך יש משהו בסגנון:

קוד PHP:

 if (isset($_REQUEST['page']) && $_REQUEST['page'] == 'logout') {
unset cookies, user variables, anything related to the user being logged in
} 


עכשיו כשהמשתמש ייכנס לאתר שלך, הוא יתנתק אוטומטית.
וזו עוד דוגמא פשוטה, זה יכל להיות משהו ברמה של query שהadmin ייכול לעשות, ואם יש עוגייה עם המשתנה הזה וערך DROP TABLE users זה יכל גם למחוק את הטבלת משתמשים...
עכשיו הקטע הוא שהעוגייה היא אחרי הPOST\GET בעת יצירת ה$_REQUEST. בPHP 5.3 אפשר לשנות את הסדר, אבל הברירת מחדל היא לפי הסדר בvariables_order.

variables_order default is "EGPCS"
request_order string This directive describes the order in which PHP registers GET, POST and Cookie variables into the _REQUEST array. Registration is done from left to right, newer values override older values.

If this directive is not set, variables_order is used for $_REQUEST contents.

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

ועכשיו תסביר לי בבקשה, מה מונע ממני לשלוח אותך (מתוך דף שלי... אותו אחד שיכול להגדיר את העוגיות), לאותו logout, ככה:

<img src="http://www.attacked-site.com/user.php?page=logout" height="1" width="1" />

כשאתה משתמש ב GET_$ "המאובטח" במקום ב REQUEST_$ ?

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

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

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

הוא יגרום לך להיות בלולאה אינסופית של logout רק אם אתה לא מנקה את הקוקי של logout (ובעצם את כל העוגיות שלך...) במהלך ה logout

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

גם לפני 5.3, אם אתה ממש מודאג, אתה תמיד יכול לרוץ על כל המפתחות של COOKIE_$, לעשות להם unset על המערך של REQUEST_$, ולהמשיך להשתמש ב REQUEST חופשי מכל הבעיות שצויינו כאן.

שימוש בעוגיות צריך לעשות רק דרך COOKIE_$ לדעתי, וכאן, דווקא כן משיקולי אבטחה (קשה יותר לדחוף עוגיה לא לגיטימית מאשר משתנה GET כפי שהדגמתי לעיל)

נמאס לכם לזכור סיסמאות? לחצו כאן!

ציטוט:

במקור נכתב על ידי שימי הוא יגרום לך להיות בלולאה אינסופית של logout רק אם אתה לא מנקה את הקוקי של logout (ובעצם את כל העוגיות שלך...) במהלך ה logout בכל מקרה, עכשיו ש 5.3 נכנס ואפשר יהיה להגדיר את זה, אז בכלל יורד כל השיקול הזה לפח... גם לפני 5.3, אם אתה ממש מודאג, אתה תמיד יכול לרוץ על כל המפתחות של COOKIE_$, לעשות להם unset על המערך של REQUEST_$, ולהמשיך להשתמש ב REQUEST חופשי מכל הבעיות שצויינו כאן. שימוש בעוגיות צריך לעשות רק דרך COOKIE_$ לדעתי, וכאן, דווקא כן משיקולי אבטחה (קשה יותר לדחוף עוגיה לא לגיטימית מאשר משתנה GET כפי שהדגמתי לעיל)

יש בזה משהו

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

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

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

גולשים רגילים יכולים לערוך כל הודעה, בלי קשר לראשיותה או לא, תוך 30 דקות ממועד כתיבתה.

נמאס לכם לזכור סיסמאות? לחצו כאן!