OWASP বিভাগ: MASVS-CODE: কোডের গুণমান
সংক্ষিপ্ত বিবরণ
যখন কোনো অ্যান্ড্রয়েড অ্যাপ্লিকেশন একটি URI-কে WebView-তে লোড করার আগে সেটির বৈধতা সঠিকভাবে মূল্যায়ন করতে ব্যর্থ হয়, তখন একটি অনিরাপদ URI লোডিং ঘটে।
এই ধরনের দুর্বলতার পেছনের মূল কারণ হলো, একটি URI একাধিক অংশ নিয়ে গঠিত , যার মধ্যে ন্যূনতমভাবে স্কিম এবং হোস্ট (অথরিটি অংশের) অবশ্যই যাচাই করা (যেমন অনুমতি-তালিকাভুক্ত করা) আবশ্যক, URI-টি কোনো WebView-তে লোড হওয়ার আগে বা অ্যাপ্লিকেশন দ্বারা অভ্যন্তরীণভাবে ব্যবহৃত হওয়ার আগে।
সবচেয়ে সাধারণ ভুলগুলোর মধ্যে রয়েছে:
- হোস্ট যাচাই করা হলেও স্কিম যাচাই না করার ফলে, একজন আক্রমণকারী একটি প্রমাণীকৃত হোস্টের সাথে
http://,content://বাjavascript://এর মতো স্কিম ব্যবহার করতে পারে। - URI সঠিকভাবে পার্স করতে ব্যর্থ হওয়া, বিশেষ করে যখন URI-টি একটি স্ট্রিং হিসেবে পাওয়া যায়।
- স্কিমটি যাচাই করা হয়েছে কিন্তু হোস্টটি নয় (হোস্ট যাচাইকরণ অপর্যাপ্ত)।
শেষোক্ত ক্ষেত্রে, এটি সাধারণত তখন ঘটে যখন অ্যাপ্লিকেশনটিকে একটি প্রাইমারি ডোমেইনের যথেচ্ছ সাবডোমেইনগুলোকে অনুমতি দেওয়ার প্রয়োজন হয়। তাই, হোস্টনেমটি সঠিকভাবে এক্সট্র্যাক্ট করা হলেও, অ্যাপটি এক্সট্র্যাক্ট করা স্ট্রিং অংশে প্রাইমারি ডোমেইনের উপস্থিতি যাচাই করার জন্য java.lang.String ক্লাসের startsWith , endsWith, বা contains এর মতো মেথড ব্যবহার করে। ভুলভাবে ব্যবহার করা হলে, এই মেথডগুলো ত্রুটিপূর্ণ ফলাফলের দিকে নিয়ে যেতে পারে এবং অ্যাপ্লিকেশনটিকে একটি সম্ভাব্য ক্ষতিকারক হোস্টকে ভুলভাবে বিশ্বাস করতে বাধ্য করতে পারে।
প্রভাব
হোস্টটি কোন প্রেক্ষাপটে ব্যবহৃত হচ্ছে তার উপর নির্ভর করে এর প্রভাব ভিন্ন হতে পারে। যেসব ক্ষেত্রে একটি WebView-তে কোনো ক্ষতিকারক URI (অর্থাৎ, যেটি ফিল্টারিং/অনুমতি তালিকা এড়িয়ে গেছে) লোড করা হয়, তার ফলে সম্ভাব্যভাবে অ্যাকাউন্ট দখল (যেমন ফিশিংয়ের মাধ্যমে), কোড এক্সিকিউশন (যেমন, ক্ষতিকারক জাভাস্ক্রিপ্ট লোড করা), অথবা ডিভাইস হ্যাক হওয়ার (হাইপারলিংকের মাধ্যমে এক্সপ্লয়েট কোড প্রবেশ করানো) মতো ঘটনা ঘটতে পারে।
প্রশমন
স্ট্রিং ইউআরআই ব্যবহার করার সময়, স্ট্রিংটিকে একটি ইউআরআই হিসাবে পার্স করা এবং স্কিম ও হোস্ট উভয়কেই যাচাই করা গুরুত্বপূর্ণ:
কোটলিন
fun isUriTrusted(incomingUri: String, trustedHostName: String): Boolean {
try {
val uri = Uri.parse(incomingUri)
return uri.scheme == "https" && uri.host == trustedHostName
} catch (e: NullPointerException) {
throw NullPointerException("incomingUri is null or not well-formed")
}
}
জাভা
public static boolean isUriTrusted(String incomingUri, String trustedHostName)
throws NullPointerException {
try {
Uri uri = Uri.parse(incomingUri);
return uri.getScheme().equals("https") &&
uri.getHost().equals(trustedHostName);
} catch (NullPointerException e) {
throw new NullPointerException(
"incomingUri is null or not well-formed");
}
}
হোস্ট যাচাইকরণের জন্য, সংশ্লিষ্ট URI অংশটিকে আলাদা করার পর, হোস্টটি বিশ্বস্ত কি না তা সঠিকভাবে শনাক্ত করতে এটিকে আংশিকভাবে নয়, বরং সম্পূর্ণরূপে যাচাই করা গুরুত্বপূর্ণ। যখন startsWith বা endsWith মতো পদ্ধতি ব্যবহার করা এড়ানো যায় না, তখন সঠিক সিনট্যাক্স ব্যবহার করা এবং প্রয়োজনীয় অক্ষর বা চিহ্ন উপেক্ষা না করা গুরুত্বপূর্ণ (উদাহরণস্বরূপ, সঠিক মিলের জন্য endsWith ক্ষেত্রে ডোমেইন নামের আগে " . " ডট অক্ষরটি প্রয়োজন হয়)। এই অক্ষরগুলো উপেক্ষা করলে ভুল মিল হতে পারে এবং নিরাপত্তা বিঘ্নিত হতে পারে। যেহেতু সাবডোমেইনগুলো অসীমভাবে নেস্টেড হতে পারে, তাই হোস্টনেম যাচাই করার জন্য রেগুলার এক্সপ্রেশন ম্যাচিং একটি প্রস্তাবিত কৌশল নয়।
অবদানকারী: মাইক্রোসফট থ্রেট ইন্টেলিজেন্সের দিমিত্রিওস ভালসামারাস এবং মাইকেল পেক