बिज़नेस लॉजिक और फ़ाइल अपलोड टेस्टिंग

यह क्यों ज़रूरी है

ये defects vulnerability scanners को शायद ही कभी मिलते हैं, क्योंकि technically कुछ भी malformed नहीं है: request valid JSON है, file valid upload है। सिर्फ़ वह टेस्टर जो समझता है कि business क्या चाहता है, देख सकता है कि discount: 100 या दूसरा confirm refuse होना चाहिए था। OWASP इस class को दो बार list करता है: Top 10 में Insecure Design (A06:2025) और API Security Top 10 में Unrestricted Access to Sensitive Business Flows (API6:2023), जहाँ purchase, booking या sign-up flow का automated abuse बताया गया risk है।

नुक़सान सीधा पैसा और भरोसा है: free orders, ख़ाली हो चुके coupons, bots द्वारा ख़रीदा गया पूरा stock, और ऐसी uploaded file जो server पर execute हो या किसी दूसरे user के browser में script चलाए। टेस्टर के लिए यह security testing का वह हिस्सा है जिसमें सबसे कम tooling और सबसे ज़्यादा सोच चाहिए, और यहीं functional testing की skills सीधे काम आती हैं।

Workflow abuse: छोड़े गए steps और बदले गए fields

हर multi-step flow एक state machine है: cart, coupon applied, awaiting payment, paid, confirmed। Browser steps क्रम में दिखाता है, लेकिन server को अलग-अलग requests मिलती हैं और उसे हर एक पर जाँचना चाहिए कि order सही state में है। Testing की शुरुआत states और उनके बीच ले जाने वाली requests की सूची से होती है, जैसे state transition testing के lesson में, फिर वे moves आज़माएँ जिनकी design इजाज़त नहीं देती: payment से पहले confirmation request भेजना, steps का क्रम बदलना (pay करने के बाद shipping चुनना), या वह step दोहराना जो एक ही बार होना चाहिए।

Tests का दूसरा group उन values को बदलता है जो server के पास होनी चाहिए। Price, discount, total, currency, role और is_admin fields को client से आना ही नहीं चाहिए; अगर आते हैं, तो उन्हें बदलें और देखें कि server दोबारा compute करता है या उन पर भरोसा करता है। Boundary value analysis से जानी negative और extreme values जोड़ें: quantity -1 (purchase के भेस में refund), 0, 999999, 101 percent का discount, 0.001 का price।

• Skip: आख़िरी step पहले भेजें। Expected: 4xx error और state में कोई बदलाव नहीं।
• Reorder और repeat: दो बार pay, दो बार confirm, ख़ाली cart पर coupon। Expected: दूसरा call refuse हो या harmless no-op रहे।
• Tamper: request में price, total, discount या role बदलें, जैसे नीचे 1,899.00 के order की payment request में। Expected: 400 या 422, या field ignore हो; दोनों हालात में server अपनी values इस्तेमाल करे और response उन्हें दिखाए। सिर्फ़ 1.00 charge करने वाला 200 ही defect है।
• Limits और reuse: एक coupon प्रति customer, तीन attempts प्रति घंटा, पाँच items प्रति order। Expected: server हर इस्तेमाल गिने, ताकि limit sessions, devices और page reload के पार भी टिके, और कुल मिलाकर सिर्फ़ एक बार इस्तेमाल होने वाला code दूसरे account से भी refuse हो।

POST /orders/8841/pay HTTP/1.1
Host: shop.example
Content-Type: application/json
Cookie: session=...

{ "payment_token": "tok_test_123", "total": 1.00, "currency": "SAR" }

आज़माएँ: स्टेट ट्रांज़िशन जनरेटर आज़माएँ: API रिक्वेस्ट बिल्डर

Race conditions: एक ही request दो बार, एक साथ

Race condition ऐसा defect है जो तभी दिखता है जब दो या ज़्यादा requests लगभग एक ही पल में एक ही record को छूती हैं। Classic case double spend है: wallet में 100 SAR हैं, 100 SAR की दो withdrawals साथ आती हैं, दोनों balance पढ़ती हैं इससे पहले कि कोई एक उसे लिखे, और दोनों सफल हो जाती हैं। यही आकार "Place order" पर double-click से दो orders, single-use coupon का दो बार redeem होना, या पाँच attempts की ऐसी limit जो छह को निकल जाने दे, पैदा करता है।

इस स्तर पर tooling से ज़्यादा concept मायने रखता है। Expected behaviour यह है कि server check और change एक ही अविभाज्य (atomic) step में करे, आम तौर पर database transaction के अंदर row lock, ऐसे update से जो तभी सफल हो जब balance अब भी काफ़ी हो, या unique constraint से, ताकि ठीक एक request जीते। Test करने के लिए वही request दो या ज़्यादा बार कम-से-कम delay के साथ भेजें (दो tabs, parallel में fire करने वाली script, या intercepting proxy का repeat function) और final state की तुलना उससे करें जो एक request को देना चाहिए था। Payment requests पर idempotency keys, जो आपको Idempotency-Key header के रूप में दिख सकती हैं, retries का design answer हैं और developer से पूछने लायक हैं।

• Double submit: order button दो बार दबा। Expected: एक order, एक charge, एक e-mail।
• Double spend: दो withdrawals या redemptions एक साथ। Expected: ठीक एक सफल हो और balance कभी शून्य से नीचे न जाए।
• Counter limits: किसी limit के ख़िलाफ़ कई parallel attempts। Expected: limit ठीक-ठीक टिके; limit के बाद वाली attempt refuse हो, requests की timing चाहे जो हो।

आज़माएँ: एज केस जनरेटर

File uploads: नाम, type, size, content और file कहाँ जाती है

Upload application को तीन चीज़ें देता है जो आपस में असहमत हो सकती हैं: extension सहित file name, multipart part के Content-Type में declared media (MIME) type, और bytes ख़ुद। पहली दो चीज़ें client अपनी मर्ज़ी से चुनता है। report.pdf नाम और application/pdf Content-Type वाली file में HTML page हो सकता है। Secure handling, जैसा OWASP File Upload Cheat Sheet बताती है, है: extensions की allow list, असली content की जाँच (उसका file signature, यानी शुरुआती bytes जो format पहचानते हैं, और images के लिए उन्हें rewrite करना), size limit, server का बनाया file name, और किसी अलग host पर या web root (वह folder जिससे web server files serve करता है) के बाहर storage, जहाँ server file को code की तरह run नहीं करेगा।

Test का दूसरा आधा यह है कि file वापस serve होने पर क्या होता है। Application के अपने origin के URL पर खुली stored HTML या SVG file user के session के साथ script चलाती है: upload से पहुँचा stored XSS। Safe responses server का तय किया exact Content-Type, X-Content-Type-Options: nosniff, और हर उस चीज़ के लिए Content-Disposition: attachment (browser file को दिखाने के बजाय download करता है) भेजती हैं जो PNG या JPEG जैसी raster image नहीं है जिसका content server ने verify किया हो, या user files को अलग domain से serve करती हैं। SVG भी image है, लेकिन उसमें script हो सकती है, इसलिए उसके साथ HTML जैसा ही व्यवहार होता है।

• Type: .jpg नाम दी गई harmless text file; text/html Content-Type से भेजी image; double extension photo.jpg.html; uppercase .PHP। Expected: आख़िरी extension, case की परवाह किए बिना, allow list में हो और content उससे मेल खाए; अकेला declared type कभी फ़ैसला न करे।
• Size: ठीक limit, एक byte ऊपर, ख़ाली file। Expected: accept; साफ़ message के साथ reject; reject या empty के रूप में handle।
• Name: ../../qa-traversal-test.png, यानी path traversal की कोशिश: अगर server original नाम से storage path बनाता है, तो हर ../ एक folder ऊपर चढ़कर upload folder से बाहर निकल जाता है (नाम unique है, ताकि defect होने पर कोई मौजूदा file overwrite न हो, बस नई file बने); 300-character नाम, spaces, Arabic letters, %00 (encoded null byte), सिर्फ़ extension वाला नाम। Expected: server के बनाए नाम से store; original नाम सिर्फ़ display के लिए, encoded।
• Served back: लौटाया URL खोलें। Expected: सही Content-Type, nosniff, attachment या अलग origin; कुछ भी run न हो।
• Storage और execution: पूछें कि files कहाँ जाती हैं और क्या वह path executable है; अगर .php या .aspx नाम वाली text file accept हो भी जाए, तो वह text के रूप में download हो, कभी execute न हो।

आज़माएँ: MIME टाइप लुकअप आज़माएँ: Content-Type वैलिडेटर आज़माएँ: स्पेशल कैरेक्टर डेटासेट जनरेटर

Worked example: single-use coupon वाला checkout

Requirement: "Customer cart में items जोड़ता है, एक coupon लगा सकता है (प्रति customer single-use, minimum order 200 SAR), payment provider से pay करता है और confirmation पाता है। Order confirm होने पर stock घटता है।" Requests हैं POST /cart/items, POST /cart/coupon, POST /orders (order बनाता है और total लौटाता है), POST /orders/{id}/pay और POST /orders/{id}/confirm।

पहले इसे states में model करें, Cart, Coupon applied, Awaiting payment, Paid और Confirmed, फिर हर forbidden move के लिए एक test, हर उस field के लिए एक test जो server के पास होना चाहिए, और हर rule की boundary values निकालें (minimum order के लिए 199.99 और 200.00, और coupon के बाद items हटाने पर दोबारा जाँच)। हर test का साफ़ oracle है: call के बाद order की state और total, GET /orders/{id} से पढ़े गए, और stock count।

#  Test                                         Expected
1  POST /orders/{id}/confirm before /pay        4xx; stays Awaiting payment
2  /pay with "total": 1.00 in the body          4xx or ignored; server total kept
3  /cart/coupon twice with the same code        second call 4xx; discount once
4  coupon on a 199.99 cart (minimum 200.00)     4xx; no discount
5  coupon on a 200.00 cart                      accepted; discount applied
6  coupon at 200.00, then an item removed       discount dropped, or /orders 4xx
7  /cart/items with "quantity": -1              4xx; cart unchanged
8  /confirm sent twice in parallel              one confirmation; stock reduced once
9  /pay on another customer's order             403 or 404 (access control)
10 coupon already used on an earlier order      4xx; no discount

आज़माएँ: स्टेट ट्रांज़िशन जनरेटर आज़माएँ: API रिक्वेस्ट बिल्डर

अक्सर पूछे जाने वाले सवाल

संदर्भ

• OWASP Web Security Testing Guide (WSTG)OWASP Foundationवेब एप्लिकेशन और API की सुरक्षा कमज़ोरियों को परखने की संदर्भ कार्यप्रणाली, एक-एक टेस्ट के रूप में।
• OWASP Cheat Sheet Series: File UploadOWASP Foundationअपलोड की गई फ़ाइलों की जाँच: एक्सटेंशन और कंटेंट-टाइप जाँच, साइज़ सीमा, वेब रूट के बाहर स्टोरेज, स्कैनिंग।
• OWASP API Security Top 10 (2023)OWASP Foundation · 2023API की दस सबसे आम कमज़ोरियाँ: ऑब्जेक्ट-लेवल ऑथराइज़ेशन का टूटना, ऑथेंटिकेशन का टूटना, अनियंत्रित रिसोर्स खपत और अन्य।
• OWASP Top 10:2025OWASP Foundation · 2025वेब एप्लिकेशन की दस सबसे गंभीर सुरक्षा जोखिम, हर एक की जाँच और रोकथाम के साथ।