פירצה ב PAYPAL בכל מקום!

[BuildDream]

יש לזה פיתרון מאוד פשוט - PayPal Express Checkout.

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

[IgalSt]

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

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

[אדיר]

כשעובדים עם IPN, בהעברת הלקוח לתשלום ב- paypal בעל האתר צריך לספק 3 קישורים שונים -
1. כתובת לחזרה במקרה שבו העסקה נכשלה (cancel).
2. כתובת לחזרה לאחר שהעסקה בוצעה (return).
3. כתובת לפנייה כאשר העסקה בוצעה בפועל, כאן גם נשלחים כל הפרטים אודות העסקה (notify_url).

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

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

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

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

[Steve-Web]

יגאל וגם אדיר, אגיב לשניכם , אני לא יודע האם להגדיר את זה כפריצה ממש , אבל ! זה בהחלט בעיה שנמצאת בהמון המון המון אתרים ישראלים וגם אחרים גדולים, קצת קשה לי להסכים עם ההשוואה של יגאל מכיוון שמדובר פה לא רק בלהחליף מדבקה אלה לעיתים גם בלי להחליף מדבקה ישר "לצאת מהחנות" עם המוצר , אני מתכוון פה ל Success return URL שנשלח גם הוא לפייפאל עם שאר הנתונים .
אדיר , ברור לי שמי שמבין בזה ולא מתעצל ויודע כמובן לעבוד נכון עם PAYPAL אין סיבה שהנתונים יישלחו ככה חשופים ללקוח או אולי חשופים אך מאובטחים ומצופנים כמו שצריך , מעבר לכך מה שאני עובד עליו זאת מערכת שתדע גם לאחר העסקה לסמן שהתשלום בוצע לא מכניסה לדף ההחזרה של ה Success return (שכמה שזה נשמע טיפשי יש המון אתרים שעובדים ככה . המון .) אלה גם מוודא שה ID של העסקה הוא אכן על הסכום כמו שמתואר באתר עצמו וכמובן שהעסקה אכן בוצעה .
אין לי ספק שאצל PAYPAL הכן תקין ואין אצלם פירצה כלשהי הבעיה כמובן היא אצל המתכנתים שעובדים בצורה פזיזה\זולה ולא משקיעים או מבינים עד כמה זה חשוב ולמה זה יכול לגרום .
חשוב לציין משהו שעלה לי בראש ישר ועדיין לא מצאתי כלכך תשובה , אכן יש לפייפאל אפשרות לעבוד עם TOKEN של העסקה ותקשורת ישירה של השרת מול PAYPAL אז למה הם נתנו אפשרות של תקשורת כזאת חשופה לצד הלקוח ולמי שקצת מבין אפשרות לשנות את הנתונים האלה ללא בעיה כלל , מוזר לי למה הדבר הזה נשאר ככה ובכל רגע עוד ועוד אתרים נבנים בצורה לקויה \ מרומים ע"י אנשים שרוצים לנצל את הדבר לרעה .

[אדיר]

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

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

העמוד היחיד שרשאי להשלים עסקה הוא העמוד שהגדרנו כ- notify_url - אין בעיה ממשית עם העובדה שהמשתמש ידע את הנתיב אליו כי הוא לא יכול לעשות איתו כלום.

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

[Steve-Web]

נכון מה שאתה אומר אבל רק בחלק מהאתרים . אני יכול לתת לך המון אתרים שעת השליחת נתונים ל PAYPAL ובניהם ה RETURN URL יש 2 כתובות , אחת של הצלחה ואחת של ביטול , (כן כן יש גם כאלה) והמערכת האוטומטית שיוצרת את הדף חזרה של "הצלחה" הוא לא דף HTML אלה PHP או ASP שמכיל נתונים שיראו במערכת האתר עצמה (לא פייפאל, לדוגמא XXXXXX - אתר הקניות שממנו רכשתי) שהתשלום בוצע בהצלחה , והפקידים של החברה שיושבים איי שם ולא כל כך מבינים פשוט מסתכלים ורואים ששולם במערכת (האישית שלהם באתר שלהם) ושולחים את המוצר ...
זה הייתה כוונתי .

[אדיר]

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

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

אז בעניין השאלה המקורית שלך:

אם כבר אז רציתי להעלות פה את הדיון הזה ולראות מה אתם חושבים שניתן לעשות ?
להשאיר את זה ככה ?

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

[IgalSt]

נא לא לפרסם שמות או לקשר לאתרים ספציפיים בהם יש בעיה לכאורה

לגופו של עניין, אני יכול אולי להגדיר את זה "כפריצה פסיכולוגית". ממש כמו בבדיחה שקיים וירוס שאתה מקבל במייל בקשה למחוק את explorer.exe בתיקיית c:\windows

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

[MasterNetwork]

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

[Steve-Web]

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