AWS WAF captcha क्या है और इसे कैसे संभालें
AWS WAF captcha, Amazon के Web Application Firewall द्वारा दिया जाने वाला challenge है, जब कोई site owner visitors की जाँच के लिए उसे configure करता है। जिस request को firewall संदिग्ध मानता है, उसे असली page के बजाय एक challenge page मिलता है। असली page लोड होने से पहले visitor को एक जाँच पास करनी होती है। अगर testing या data इकट्ठा करते समय यह सामने आए, तो आपको पहचानना आना चाहिए, जानना चाहिए कि site owner क्या नियंत्रित करता है, और यह भी कि Scarnox आज क्या कर सकता है। यह guide इन तीनों बातों को कवर करती है।
AWS WAF captcha क्या है
AWS WAF एक rules engine है जो किसी web application के सामने बैठता है, Amazon CloudFront, Application Load Balancer या API Gateway पर। Rules किसी request को allow, block, count या challenge कर सकते हैं। Challenge एक silent JavaScript check हो सकता है या एक दिखने वाला captcha puzzle, यह इस पर निर्भर करता है कि rule कैसे सेट है।
मुख्य बात यह है कि फ़ैसला site owner लेता है। Firewall को आपके scraper का मकसद नहीं पता होता। वह केवल उस traffic को score करता है जो उसे दिखता है: requests की rate, IP reputation, headers और client का व्यवहार।
Code में इसे कैसे पहचानें
AWS WAF challenges अक्सर उनके responses से पहचाने जा सकते हैं। एक आम संकेत x-amzn-waf-action response header है, और challenge अक्सर असली page दिखने से पहले HTTP status 202 के साथ आता है। इन्हें प्रमाण नहीं, संकेत मानें, क्योंकि sites firewall को अलग-अलग तरीके से configure करती हैं:
import requests
def looks_like_aws_waf(resp: requests.Response) -> bool:
# यह एक header संकेत है, प्रमाण नहीं। जिस page की test कर रहे हैं, उससे पुष्टि करें।
return "x-amzn-waf-action" in resp.headers
resp = requests.get("https://example.com/products", timeout=30)
if looks_like_aws_waf(resp):
print("Challenge served. Stop, slow down, and check your request rate.")
else:
print("Status", resp.status_code)Page source में उस script को भी देखें जो AWS WAF challenge path से लोड होती है, और ऐसे page को भी जो तब तक कोई content नहीं दिखाता जब तक script न चले। सादा requests call अक्सर असली data के बजाय challenge page पाएगा। यह अपेक्षित है।
Site owner क्या कर सकता है
अगर आप site चलाते हैं, तो AWS WAF console आपको वे rules tune करने देता है जो challenge ट्रिगर करते हैं। सबसे उपयोगी विकल्प ये हैं:
- Rate-based rules जो केवल उन clients को challenge करें जो बहुत ज़्यादा requests भेजते हैं, ताकि सामान्य visitors पास हो जाएँ।
- Allowlists अपने monitoring, CI या partner IP ranges के लिए, ताकि आपकी अपनी tests challenge न हों।
- केवल संवेदनशील paths पर challenge, जैसे login या checkout, न कि पूरी site पर।
अगर आप अपनी ही site की testing कर रहे हैं, तो सबसे साफ़ समाधान है अपने test runners के लिए allowlist। जो site आपकी नहीं है, उस पर challenge को पार करने की कोशिश न करें। यह owner की सुरक्षा है, और यही वह पहली चीज़ है जो आपकी पहुँच तोड़ देगी।
Scarnox support कहाँ है
- अभी उपलब्ध: PopularCaptcha, proxyless और अपने proxy के साथ।
- जल्द आ रहा है: AWS WAF, साथ में GeeTest, reCAPTCHA v2 और v3, Cloudflare Turnstile और Arkose। जब तक किसी solve को live के रूप में सूचीबद्ध न किया जाए, उस पर निर्भर production flow न बनाएँ।
तो अगर कोई site, जिसके साथ आप काम करने के लिए अधिकृत हैं, आज AWS WAF challenge दिखाती है, तो विकल्प ऊपर वाले ही हैं: धीमे चलें, अगर site आपकी है तो allowlist इस्तेमाल करें, या site owner से API या data feed माँगें। आप खाता बनाएँ और मुफ़्त ट्रायल क्रेडिट से शुरू करें, कार्ड की ज़रूरत नहीं, ताकि अभी अपना PopularCaptcha flow सेट कर सकें और AWS WAF support आने पर तैयार रहें। मौजूदा pricing pricing page पर है।
AWS WAF के पीछे अपनी site की test करें
अगर आप site owner हैं और चाहते हैं कि automated tests firewall पास करें, बिना असली visitors के लिए उसे कमज़ोर किए, तो challenge के आसपास से निकलने के बजाय firewall के अपने tools इस्तेमाल करें:
- एक नया rule count mode में शुरू करें। यह उन requests को रिकॉर्ड करता है जिन्हें challenge किया जाता, बिना किसी को प्रभावित किए, ताकि आप देख सकें कि आपकी tests क्या ट्रिगर करती हैं।
- WAF logging Amazon CloudWatch Logs, Amazon S3 या Amazon Data Firehose पर चालू करें। Log बताता है कि कौन-सा rule match हुआ और किस header या path ने उसे ट्रिगर किया।
- Test environment को अपना अलग staging domain और अलग rule set दें, ताकि production सुरक्षित रहे और आपका suite बेरोकटोक चले।
- केवल वही IP ranges या header values allowlist करें जो आपके test runners इस्तेमाल करते हैं, और जब भी runners बदलें तब उस list की समीक्षा करें।
ये कदम protection को बनाए रखते हैं और test traffic को अनुमानित बनाते हैं, जो असल में आपको चाहिए। अपने test setup में हर बदलाव के बाद rules की समीक्षा करें, क्योंकि पिछले महीने के runners के लिए जो rule सही था, वह अब उन्हें block कर सकता है।
ज़िम्मेदारी से scrape करें
अगर AWS WAF page तक पहुँचने का कारण data इकट्ठा करना है:
- Requests भेजने से पहले site का
robots.txtऔर terms of service पढ़ें। - Request rate कम रखें। Challenge अक्सर site का आपसे धीमे चलने को कहने का तरीका होता है।
- रुकें जब site साफ़ तौर पर नहीं चाहती कि उस तक automated access हो।
- वह personal data इकट्ठा न करें जिसे रखने का कोई कारण नहीं है, और जो data इकट्ठा करें उसे लागू privacy नियमों के तहत संभालें।