ক্রস সাইট অনুরোধ জালিয়াতি
ক্রস-সাইট অনুরোধ জালিয়াতি' (বা ''CSRF) হল এক ধরনের আক্রমণ যা ওয়েব অ্যাপ্লিকেশনের নিরাপত্তার দুর্বলতা কাজে লাগাতে ওয়েব ব্রাউজার ক্যাশিং আচরণ ব্যবহার করে।
CSRF আক্রমণগুলি ক্ষতিকারক এইচটিটিপি অনুরোধ অনুমোদন করার জন্য একজন শিকারের ব্রাউজারে (যেমন একটি কুকি বা ক্যাশে করা ব্যবহারকারীর নাম এবং পাসওয়ার্ড) ক্যাশ করা প্রমাণীকরণ শংসাপত্র ব্যবহার করে। ক্ষতিকারক HTTP অনুরোধ অনেক উপায়ে পাঠানো যেতে পারে। যতক্ষণ না অনুরোধগুলি একটি ওয়েব ব্রাউজার দ্বারা প্রক্রিয়া করা হয় যাতে ক্যাশে প্রমাণীকরণ শংসাপত্র রয়েছে, একটি CSRF আক্রমণের চেষ্টা করা যেতে পারে। এর উদাহরণগুলির মধ্যে রয়েছে:
- লিঙ্কগুলি ইমেল বার্তাগুলিতে অন্তর্ভুক্ত যা শিকার দ্বারা একটি ব্রাউজারে খোলা হয়
- HTML-ফরম্যাটেড ইমেলে এমবেড করা ইমেজ ট্যাগ (যা পরবর্তীতে একটি ওয়েব ইমেল ক্লায়েন্টে দেখা হয়)
- একটি ওয়েব পেজে এমবেড করা ফর্ম
- জাভাস্ক্রিপ্টের মাধ্যমে করা AJAX-শৈলী অনুরোধ
সফল হলে, আক্রমণ আক্রমণকারীকে শিকারের মতো একই স্তরের অনুমতি সহ একটি ওয়েবসাইটে অ্যাকশন করার অনুমতি দিতে পারে।
ক্রস-সাইট অনুরোধ জালিয়াতির একটি বিস্তৃত ওভারভিউয়ের জন্য, উইকিপিডিয়ার ক্রস-সাইট অনুরোধ জালিয়াতি পাতা পর্যালোচনা করুন।
উদাহরণ
The following code snippet helps demonstrate how a CSRF attack could occur. Assume that there are no other checks or protections in place to prevent an attack.
$user = $out->getUser();
$request = $out->getRequest();
if ( $user->isAllowed( 'delete' ) && $request->wasPosted() && $request->getCheck( 'delete' ) ) {
$this->deleteItem( $request->getText( 'delete' ) );
}
The code allows a user to delete an item in wiki, as long as they have sufficient permissions and are authenticated.
If an authenticated user is tricked into visiting an external webpage under the control of an attacker, then the attacker can forge a request and send it to the wiki. The wiki would receive the request, check for authentication credentials, and then run the forged request as if it had actually been made by the victim.
Defending MediaWiki against CSRF attacks
We reduce the risk of CSRF attacks in MediaWiki using pseudo-random challenge tokens. These tokens are generated for each page that an authenticated user visits.
When submitting a form for a given page, the submission must include the token. Submissions that do not include the token will fail. It is difficult for attackers to guess or steal these tokens, making CSRF attacks more difficult.
Thanks to JavaScript's same origin policy, attackers cannot easily use JavaScript to read the challenge token from the form.
Implementing Challenge Tokens
Challenge tokens should be added to all forms and all APIs that can make a change (edit, update, delete, block etc.). You might want to look into migrating your code to HTMLForm, which has support for CSRF protection.
HTML Forms
To add the tokens, use the getEditToken() method from the current request's User instance.
The code will look like this:
function showForm( $out ) {
...
$user = $out->getUser();
$out->addHTML( Html::hidden( 'token', $user->getEditToken() ) );
...
}
function submitForm() {
...
if ( !$user->matchEditToken( $request->getVal( 'token' ) ) ) {
... CSRF detected - stop the request right now ...
return;
}
// OK, continue submit
...
}
Every form which performs a write operation should be protected in this way.
APIs
If an API performs write operations, it should override isWriteMode to return true and needsToken to return a string indicating the correct token type (usually 'csrf').
Generally, mustBePosted should also return true in this case.