ברירות מחדל יכולות להטביע אותך

TL;DR: התייחס לתגובות לא ידועות כאל לא מורשות, לא כתקפות.

בעיות

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

פתרונות

1. אמת את כל התגובות מול קבוצה סגורה של קודים ידועים.
2. ברירת מחדל (ולא ידוע) לברירות מחדל לא מורשות או הסרה .
3. רשום כל מקרה לא תואם או לא צפוי לניתוח.
4. בדיקה עם תרחישי קצה.
5. סנכרן את מאגרי התגובות עם המעבדים באופן קבוע כדי למנוע קודים מיושנים.
6. התמקדות באבטחה מה שהופך אותו לתהליך העברה שמאלה.
7. תכנן מערכות עם עמידות לשינוי כדי להתמודד עם תרחישים מתפתחים.

הֶקשֵׁר

היום הוא יום אבטחת המחשב וכל מתכנת צריך להכיר באחריות שלו.

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

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

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

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

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

הכנסות הפלטפורמה צונחות, מה שמוביל לפשיטת רגל.

קוד לדוגמה

טָעוּת

 String response = paymentProcessor.authorize(cardDetails); switch (response) { case "DECLINED_INSUFFICIENT_FUNDS": // Handle insufficient funds break; case "DECLINED_EXPIRED_CARD": // Handle expired card break; default: // Authorize purchase break; }

יָמִינָה

 String response = paymentProcessor.authorize(cardDetails); switch (response) { case "APPROVED": // Authorize purchase break; case "DECLINED_INSUFFICIENT_FUNDS": // Handle insufficient funds break; case "DECLINED_EXPIRED_CARD": // Handle expired card break; case "DECLINED_NEW_REASON": // Handle new declined reason break; default: // Reject purchase (default case for unknown responses) break; }

איתור

• [x] ידני

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

בדוק אם המערכת מתעדת ומכחישה מקרים לא מזוהים.

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

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

תגים

• בִּטָחוֹן

רָמָה

• [x] ביניים

למה ביג'יון חשוב

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

כאשר אתה שובר את ה- Bijection , אתה יוצר אי התאמה.

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

דור AI

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

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

זיהוי AI

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

נסה אותם!

זכור: עוזרי AI עושים הרבה טעויות

מַסְקָנָה

תמיד לטפל במקרים לא ידועים בזהירות.

ברירות מחדל כמו "לא נמצא" עלולות להוביל לבעיות אבטחה חמורות ולהפסדים כספיים.

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

קבל החלטות משמרת שמאלה הקשורות לאבטחה בזמן התכנות.

יחסים

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxii

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-viii-8mn3352

כתב ויתור

ריחות קוד הם דעתי .

קרדיטים

תמונה מאת Nathana Rebouças ב- Unsplash

https://www.youtube.com/watch?v=J2QOejhA6ek

ההנחות הן אם כל הכישלונות.

אמר וייסל

הנדסת תוכנה ציטוטים מעולים

מאמר זה הוא חלק מסדרת CodeSmell.

כיצד למצוא את החלקים המסריחים של הקוד שלך