अपने वेब ऐप का बचाव: दर सीमित करने और क्रूर बल के हमले की रोकथाम के लिए एक गाइड

यदि आपके एप्लिकेशन में लॉगिन, पंजीकरण, पासवर्ड रीसेट/पुनर्प्राप्ति, पुष्टिकरण लिंक दोबारा भेजने और सर्वर अनुरोधों की आवश्यकता वाली अन्य विशिष्ट कार्यक्षमताएं जैसी मूलभूत सुविधाएं शामिल हैं, तो क्रूर बल के हमलों और आपकी सेवा पर पर्याप्त भार उत्पन्न करने के खिलाफ तंत्र को लागू करना महत्वपूर्ण है। ऐसे तंत्र के बिना, आपका एप्लिकेशन विभिन्न खतरों के प्रति संवेदनशील हो सकता है, जिसमें उपयोगकर्ताओं को अत्यधिक संख्या में ईमेल/ओटीपी भेजना शामिल है, जिससे संभावित रूप से वित्तीय और प्रतिष्ठा को नुकसान हो सकता है।

कई वेब अनुप्रयोगों में पर्याप्त दर-सीमित उपायों का अभाव होता है, जो पूरी तरह से उनके व्यावसायिक तर्क द्वारा लगाई गई सीमाओं पर निर्भर होते हैं, जैसे भुगतान मॉडल के आधार पर अनुरोधों की संख्या को सीमित करना। हालाँकि, कुछ एप्लिकेशन दर सीमाएँ शामिल करते हैं, विशेष रूप से लॉगिन प्रयास, पंजीकरण और अन्य महत्वपूर्ण कार्यात्मकताओं जैसे कार्यों के लिए। ये कार्यान्वयन अक्सर आईपी एड्रेस ट्रैकिंग के लिए एक्स-फॉरवर्डेड-फॉर हेडर पर निर्भर करते हैं।

एक सरल उदाहरण को स्पष्ट करने के लिए, मैं फ्लास्क पर इस कोड स्निपेट के साथ आया

 from flask import Flask, request, jsonify from flask_limiter import Limiter from flask_limiter.util import get_remote_address app = Flask(__name__) limiter = Limiter(    app,    key_func=get_remote_address,    storage_uri="memory://",) def get_ipaddr():    # Retrieve the client's IP address from the request    # X-Forwarded-For header is used to handle requests behind a proxy    ip_address = request.headers.get('X-Forwarded-For', request.remote_addr)    return ip_address # Rate limit to 5 requests per minute per IP @limiter.limit("5 per minute") @app.route('/') def index(): ip_address = get_ipaddr() return ip_address

निम्नलिखित अनुभागों में, मैं आपके एप्लिकेशन में परीक्षण और दर सीमाओं को बायपास करने के प्रयास के विभिन्न तरीकों के बारे में बताऊंगा।

इस प्रकार की भेद्यता के लिए अपने ऐप का कुशलतापूर्वक परीक्षण करने के लिए, स्वचालन एक शक्तिशाली उपकरण है। आप इसे स्क्रिप्ट्स को नियोजित करके प्राप्त कर सकते हैं, जैसे कि पायथन में (जैसा कि मैं अक्सर करता हूं), या बर्प सूट जैसे टूल का उपयोग करके (वैसे परीक्षकों और साइबर सुरक्षा पेशेवरों के लिए एक महान टूल)। इसके अलावा, चेक को अपेक्षाकृत आसानी से स्वचालित करने के लिए पोस्टमैन जैसे टूल का उपयोग किया जा सकता है।

परीक्षण दर सीमा

एक्स-फॉरवर्डेड-फॉर हेडर में आईपी मान बदलना

 X-Originating-IP: 127.0.0.1

आपके द्वारा भेजे जाने वाले प्रत्येक अनुरोध में भिन्न IP मानों का उपयोग करें।

डबल एक्स-फॉरवर्ड-फॉर हेडर का उपयोग करें।

 X-Forwarded-For: X-Forwarded-For: 127.0.0.1

अलग-अलग हेडर के साथ भी ऐसा ही प्रयास करें।

 X-Originating-IP: 127.0.0.1 X-Remote-IP: 127.0.0.1 X-Remote-Addr: 127.0.0.1 X-Client-IP: 127.0.0.1 X-Host: 127.0.0.1 X-Forwared-Host: 127.0.0.1

अन्य शीर्षलेख बदलें

उपयोगकर्ता-एजेंट, सामग्री-प्रकार, स्वीकार्य-भाषा, आदि, या कुकीज़, कुछ भी बदलने का प्रयास करें जिसका उपयोग उपयोगकर्ता पहचानकर्ता के रूप में किया जा सकता है।

यदि प्रति आईपी 3 प्रयासों की दर सीमा है, तो हर तीन प्रयासों में, हेडर (या आपके अनुरोधों में अन्य हेडर या पैरामीटर) का आईपी मान बदलें।

पैरामीटर्स में रिक्त वर्ण जोड़ें

आपके द्वारा भेजे गए पैरामीटर में जोड़ने का प्रयास करें

 %00, %0d%0a, %0d, %0a, %09, %0C, %20

उदाहरण के लिए

 param1=value1%%0d%0a param2=value2%00

उदाहरण के लिए, यदि आप ईमेल सत्यापन के लिए ओटीपी का अनुरोध कर रहे हैं और आपके पास केवल 3 प्रयास हैं, तो 3 प्रयासों का उपयोग करें

 [email protected] [email protected]%00 [email protected]%0d%0a And so on

समान समापन बिंदुओं का उपयोग करें

यदि आप परीक्षण कर रहे हैं, उदाहरण के लिए,/एपीआई/v1/साइनअप एंडपॉइंट, तो /साइनअप, /साइनअप, /साइन-अप के लिए ब्रूट-फोर्स निष्पादित करने का प्रयास करें। मूल समापनबिंदु में रिक्त वर्ण (ऊपर से) जोड़ने का प्रयास करें।

अनुरोधित एपीआई समापन बिंदु पर अतिरिक्त पैरामीटर जोड़ना

यदि सीमा /api/v1/resetpassword एंडपॉइंट के अनुरोधों पर है, तो कुछ क्वेरी पैरामीटर जोड़कर इसे बलपूर्वक लागू करने का प्रयास करें - एक बार दर सीमा तक पहुंचने के बाद, उदाहरण के लिए, /api/v1/resetpassword?param1=value1 आज़माएं

लॉगिन मायने रखता है

ऐसा हो सकता है कि किसी ऐप में त्रुटिपूर्ण तर्क हो - यदि आप प्रत्येक प्रयास/प्रयासों की श्रृंखला से पहले अपने खाते में लॉग इन करते हैं, तो आपके आईपी के लिए दर सीमा रीसेट हो जाती है, और आप अपना पासवर्ड ब्रूट-फोर्स अटैक जारी रख सकते हैं। यदि आप लॉगिन सुविधा का परीक्षण कर रहे हैं, तो आप प्रत्येक प्रयास/प्रयास की श्रृंखला के लिए बर्प सूट में पिचफोर्क हमले के साथ सेटिंग्स में ऐसा कर सकते हैं (या आप इसके लिए अपनी स्क्रिप्ट लिख सकते हैं)।

यहां मेरा उदाहरण है कि कैसे मैंने POW प्राप्त करने के लिए X-Forwarded-For हेडर के लिए एक सरल जांच को स्वचालित किया:

 from random import randint import requests import json url = "https://yourapp.net/api/v1/regconfirm-resend" data = {   "email": "[email protected]" } N = 100 def generate_random_ip():   return '.'.join(       str(randint(0, 255)) for _ in range(4)   ) for _ in range(N):   headers = {       "Host": "yourapp.net",       "Content-Type": "application/json",       "X-Forwarded-For": generate_random_ip()   }   response = requests.post(url, headers=headers, data=json.dumps(data))   print(headers)   print(f"Status Code: {response.status_code}, Response: {response.text}")

मूल विज़िटर आईपी को पुनर्स्थापित करना

एक संभावित समाधान क्लाउडफ्लेयर और उसके तंत्र का उपयोग हो सकता है। एक विस्तृत विवरण यहां रिस्टोरिंग-ओरिजिनल-विज़िटर-आईपीएस पाया जा सकता है। मैं इसके रक्षा तंत्र का केवल एक संक्षिप्त विवरण प्रदान करूंगा।

यदि आप ऐसे एप्लिकेशन का उपयोग करते हैं जो मूल विज़िटर के आने वाले आईपी पते पर निर्भर करते हैं, तो क्लाउडफ़ेयर आईपी पता डिफ़ॉल्ट रूप से लॉग किया जाता है। मूल विज़िटर आईपी पता सीएफ-कनेक्टिंग-आईपी नामक एक संलग्न HTTP हेडर में दिखाई देता है। हमारे वेब सर्वर निर्देशों का पालन करके, आप अपने मूल सर्वर पर मूल विज़िटर आईपी पता लॉग कर सकते हैं। यदि अनुरोध आपके मूल सर्वर तक पहुंचने पर यह HTTP हेडर उपलब्ध नहीं है, तो अपने ट्रांसफॉर्म नियम और प्रबंधित ट्रांसफॉर्म कॉन्फ़िगरेशन की जांच करें।

यदि छद्म आईपीवी4 को ओवरराइट हेडर पर सेट किया गया है - तो क्लाउडफ्लेयर सीएफ-कनेक्टिंग-आईपीवी6 हेडर में वास्तविक आईपीवी6 पते को संरक्षित करते हुए मौजूदा सीएफ-कनेक्टिंग-आईपी और एक्स-फॉरवर्डेड-फॉर हेडर को छद्म आईपीवी4 पते के साथ अधिलेखित कर देता है।

ध्यान दें: याद रखें, ऐसे रक्षा तंत्र को लागू करते समय, पूरी तरह से परीक्षण करें। इस दृष्टिकोण को बाद में पूरे क्लस्टर पर लागू किया जा सकता है और जहां यह अनावश्यक है, वहां कुछ कार्यों और माइक्रोसर्विसेज पर प्रतिकूल प्रभाव डाल सकता है। संक्षेप में, सुरक्षा उल्लंघन को ठीक करते समय सावधान रहें, क्योंकि यह संभावित रूप से पूरे एप्लिकेशन को प्रभावित कर सकता है। विश्लेषण करें कि आपके सिस्टम का कौन सा हिस्सा नकारात्मक रूप से प्रभावित हो सकता है और उत्पाद पर्यावरण में शिपिंग परिवर्तन से पहले हर चीज का परीक्षण करें।

यहाँ भी प्रकाशित किया गया है.