מחפש מישהו שיבדוק לי SQL INJECTION
 

http://www.sportn.co.il/ זה האתר
תיכנסו תעברו על האתר תבדקו אם יש אפשרות להזרקת SQL
עשיתי איזה אבטחה קטנה ב php...
נקווה שזה טוב

עכשיו אני רוצה לראות אותך נכנס לדף הזה:
http://www.sportn.co.il/search/index...bmit=%E7%F4%F9
(תיכנס לדף כלשהו ואחר כך לדף הזה.)

ותריץ חיפוש של התו %, הוא משמש לך בחיפוש WILDCARD ואני לא בטוח שזה מה שאתה רוצה.
זה רק מהחיפוש, אין לי כוח להמשיך..


עריכה:
הינה משהו קטן שיתקע לך את האתר:
http://www.sportn.co.il/search/index...bmit=%E7%F4%F9

http://www.sportn.co.il/news/index.php?newsID=3'
תטפל בבלוק הימני.

CSS זה יותר מגניב ;P
http://www.sportn.co.il/search/index...bmit=%E7%F4%F9

ואני לתומי חשבתי שהוא מחפש SQL Injections.

אני חושב שחסמתי תבדקו שנייה

מה הקשר? זה לא אומר שהוא לא צריך להגן XSS.

ולא תיקנת את הWILDCARD.

בלי קשר לנושא שלך הקידוד לא טוב... אם אני כותב בחיפוש משהוא ארוך הוא לא מאריך את הבלוק תוכן עשית עבודה קלה וקידדת את הבלוק ביחד אם הצדדים לא מומלץ
דוגמא:
http://www.sportn.co.il/search/index...bmit=%E7%F4%F9

זה אתר שמכרת? אתר עם הזרקות XSS?

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

מה אתה אומר.


ואם בגלל זה הסקריפט יקרש?

אתה פונה אליי? למה אתה מתכוון "יקרש"? כי אני לא קרש =)

יקרש- ישבר, יקרוס.

וכן פניתי אליך.

לא הבנתי למה אתה לא משתמש בINTVAL, דניאל, זה TYPE CASTING רגיל.
ולא הבנתי למה אמרת שהסקריפט יקרוס בגלל זה, אלמוג. מה הקשר?

במקרה הזה אומנם לא.

אבל במקרה שבו אני מזין לתוך שאילתה מספר, ולא בודק אותו עם intVal או floatVal, השאילתה פשוט תגרום למערכת לקרוס[במידה והיא לא תיקנית].
מה גם שלפעמים צריך לשקול את המצב ובמקום לבדוק אם הנתון מספר[is_numeric או is_int etc..], הרבה יותר חכם לעשות intVal. מכוון שלפעמים כשהמשתמש לא מזין מספר הוא מפסיד מזה. אך כשהמספר נדרש יש לוודא שהערך הינו מספרי.


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

תכינו לעצמכם דף.
ותכתבו בו, "אני יודע שכל הנתונים שמגיעים אליי - צריכים להיות מוגני XSS ו-SQL INJECTION" = הברחת תגי HTML ו-SQL.

אצלי זה שחור לבן. מצידי, כל עוד אני יודע, ש-$this->input['val'] מוגן, לא אכפת לי לעשות,
המערכת לא תקרוס בגלל זה, ובאותה מידה, אתה יכול להגיד, שאם עושים מחשבון, צריך לוודא שהמספר שהכניסו לא גדול מ-2 בחזקת 32, כי אז המערכת לא תדע לחשב אותו(אלא אם כן נמיר אותו).

שחור ולבן, שחור ולבן.

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

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

לדוגמא, אצלי כבר הרבה זמן יושבת המחלקה Fetch בקוד.
היא מטפלת לי בPOST, GET, COOKIES ומערכים שאני מגדיר ידנית.
הפונקציות שהיא מכילה הן:
is שמקבילה לisset
is_empty שמקבילה לempty
is_int שמבצעת המרה לINT ע"י TYPE CASTING
is_bool, כמו למעלה
is_string
is_float
והכי חשובה -
secure - מבצעת החלפה של תווי HTML והזרקות XSS.


עכשיו, בעת קריאה לדף, הכל נכנס לARRAY בצורת ברירת מחדל - ואם צריך, אני פשוט רושם $post->secure('val') ומקבל ערך מאובטח. למשל, לTEXTAREA אני לא עושה את זה.


עכשיו בוא תסביר לי, איך $this->input['val'] מוגן, בלי לאבטח אותו אפילו פעם אחת? אתה טוען שלא צריך לבצע את הפעולה הזאת.

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

לא חכם במיוחד.. אני מדגיש את העניין של TEXTAREA, לדוגמא, שצריך בסה"כ addslashes.

למה? ב-textarea אפשר להכניס HTML, מה תעשה נגד זה?

אני מדבר על TEXTAREA כמו FCK או סתם אחד שמוסיף תגים ל-HEAD.
לא נתקלת באחד כזה?

ובקשר לאתר תחפשו לי חורי אבטחה תיקנתי את מה שאמרתם ..

נתקלתי, אבל רק לעשות addslashes מאוד מאוד מאוד לא מאובטח.

במידה ואני רוצה HTML, אני יכול להשתמש ב-
$this->rawinput['val']

ובמידה ואני רוצה שזה יהיה גם מאובטח, אז,
$this->securedhtml['val']

גם פלט של עורך חכם בלי לטפל זה חור אבטחה.

שוב, לעשות מה שעשית זה בזבוז משאבים.
להריץ פונקציה מראש על X איברים שיהיו לך.. זה בזבוז של משאבים * X


ותביא לי דוגמא איך אפשר לפרוץ TEXTAREA שאני מחליט מראש לאפשר בו HTML, בגלל שאני מאבטח אותו רק עם ADDSLASHES.

ג'אווה סקריפט?

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

וכשהמנהל מעוניין שיוכל למנות צוות כתבים/עוזרים? כיצד תריץ את הסינון המתאים?

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

ובמידה והוא רצה לעשות בכותרת, "החיים <הם> טובים", וזה יסתיר את ה"<המ>"?

אני אומר, אם בשביל עוד 10 אלפיות שניה(/מאית) אני בטוח מכל הכיוונים - לא אכפת לי להוסיף את המאית הזאת, ואי אפשר לדעת, לעשות כל פעם mysql_real_escape_string, htmlspecialchars, intval - אולי המשקל שאתה מוסיף, שזה עוד 60 בייטים! אחרי שאתה מוסיף את זה בקובץ מספיק, בגלל הנפח הגדול(אם יש 20 ערכים שאתה עושה להם את זה), זה כבר 1200 בייטים! שזה יותר מקילובייט! ואז לשרת יקח יותר זמן לעבד את זה!

בכל דבר אתה יכול להגזים, אבל אם אומרים לי, "אנחנו לוקחים מאית כל פעם ומבטיחים הגנה מלאה" - אני לוקח. ואני יודע, לעומת המתכנתים שבפורום שעושים את הדברים הבאים.
1. עושים אם יש בכתובת/בדבר הנשלח SELECT, DELETE, או UNION - נותן באן.
למה לא טוב? שלחתי בהודעה בטעות SELECT/DELETE, האתר המתחרה בכוונה נותן קישור לדף עם SELECT בכתובת כדי שלא יוכלו להיכנס, בסוף יהיו פקודות חדשות
2. str_replace("<script"), mysql_real_escape_string כדי למנוע ג'אווה סקריפט - קל מאוד מאוד לעקוף את זה.

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

הפעם היחידה שאני עושה סינון, זה ב-htaccess - אבל זה רק למען הנוחות. אני עובד עם htaccess באופן מלא.

תחליט אתה, מאית שניה ואבטחה מלאה או לא?

כמו כן, בגלל שרוב ה"מתכנתים" כאן ישתמשו במערכים של קלט מהמשתמש בלי בדיקת isset, ואם הם שומרים USER_AGENT / HTTP_REFERER בלי שום סינון, ואם הם מסתמכים על $_SERVER["HTTP_X_FORWARDED_FOR"] בשביל לגלות IP, בסופו של דבר, יחסית לרוב ה"מתכנתים" בהוסטס - השיטה שלי יותר יעילה - והרבה יותר בטוחה.

יחסית למתכנתים מחוץ לבועה - חלק חלק, אבל אם אתה שואל את עצמך, האם תקריב מאית שניה בשביל 100&#37; אבטחה, אני מנחש שתענה כן?

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

ועם FCK אין שום בעיה לכתוב החיים <הם> טובים, אתה יודע.

SCRIPTS? אז אני מריץ ביטוי PREG ברמה בסיסית וחוסם.
STYLES? אותו חרא.

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

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

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

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

חוץ מזה, שאם IPB בנוי ככה, ואם vBulletin בנוי ככה, ואם עוד הרבה מערכות מאוד גדולות בנויות ככה, יש היגיון, מסכים?

אני פשוט לא מבין מה לכל הרוחות עובד לך בראש?!

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


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

אני אתחיל מזה שאין מצב שאני קורא למשתנה לא מאובטח.
עם המחלקת FETCH שהכנתי, אני פשוט יודע אם אני צריך להשתמש בSECURE (פונקצית מחלקה) או לא. זה לא מסבך כ"כ: או secure($val) או the($val).

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

אני לא מבין למה אתה מתכוון - בלתי אפשרי להבין מהצד קוד שבנוי ככה? במקום $_POST, אתה משתמש ב-$this->input.

זה נכון שבאותה המידה אפשר לעשות, $this->input('val') - ואז זה עוד קריאה לפונקציה - משאבים, משאבים, שבאמת בהבדל של כמה מאיות?

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

ולא הגבת על הנקודה שהצגתי - אם גם vBulletion, וגם IPB, וגם עוד כמה מערכות גדולות משתמשות בדיוק בשיטה הזאת - זה לא מראה שזה לא בטוח טעייה?

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

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


שניהם, רק תגידו, בעד כמה מאיות בהנחה שיש עשרות קלטים, אתם "תקנו" אבטחה מלאה לאתרכם?


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

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

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

ד"א, אין הרבה היגיון בלעבוד עם COOKIES לשמירת מידע משתמש. אם הצליחו איכשהו לסנן לך JS לאתר, אם דרך הFTP או דרך האתר עצמו, המידע שלך הלך.

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

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

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

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

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

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

גם וגם, הסשן זה לאימות נוסף, יש לי טבלה cms_members_sessions

עוגיות הם רק לאקסטרה., אבל אני הכנתי משהו, ולא מכניסים לשם JS =)

אני יודע! אני עובד מול טבלת סשנים! אבל הסשן זה עוד אימות קטנטן.

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

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

מי אמר שאני שומר נתונים כפולים? יש לי רק $this->input, במידה ואני רוצה משהו שלא יהיה באינפוט - בתחילת הדף, אני "מודיע" לו שבמקום לסנן אותו, לא יסנן. המערכים הכפולים נמחקים.

אני חייב לציין שאתה פשוט בזבזן משאבים כפייתי.

גם קוקיז, גם SQL, וגם סשן.
מה הלאה? תמציא את הקוקיז?!

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

וויכוח ארוך וטיפשי כולכם אומרים בעצם כמעט את אותו הדבר

השיטה שאני משתמש , באופן אוטומטי אני עובר על המערכים של GET POST REQUEST SESSION ו COOKIE
ומחליף את כל התווים כדוגמאת " , ' וכו' בקוד ASCII שלהם

בעת הכנסה למסד אני גם עושה מעבר אוטומטי על המערך שאני מכניס למסד ובודק אם זה ערך מספרי מוסיף לו INTVAL / FLOATVAL ואם זה טקסט אז מוסיף ADDSLASES
באופן אוטומטי ושומר את זה במסד.
כמובן שאני מסנן מ SCRIPT וכד'
בהצגה אני מחליף את זה את הקודים של ה ASCII בחזרה ל <>" , ' ודומיהם... אבל לא תמיד, תלוי בתצוגה , אם זה משהו שמנהל הכניס (לדוגמא מתוך TINYMCE - אז כן)
אם לא אז אני לא מחליף ובמקרה הכי גרוע זה מוצג כ ASCII על המסך...

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

הסתבכתם לגמרי עם כל הנושא
ד"א

MASTER T אל תהיה כזה פרנואיד, אתה לא בונה מערכת לבנק....

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

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