Mass Assignment: ওয়েব এপিআই-এর দুর্বলতা কাজে লাগিয়ে ব্যবহারকারীর প্রিভিলেজ বৃদ্ধি!
Mass Assignment Vulnerability কীভাবে কাজ করে, বাস্তব Exploit এবং Framework-Specific Defense Pattern।
আধুনিক Web Application Framework Developer-এর জীবন সহজ করেছে। Ruby on Rails, Django, ASP.NET Core, Spring Boot, Laravel - এই সব Framework-এ একটি HTTP Request-এর JSON Body সরাসরি একটি Model Object-এ Map করার সুবিধা আছে। এটি Productivity বাড়ায়, কিন্তু একটি বিপজ্জনক Vulnerability-র দরজাও খুলে দেয় - Mass Assignment। 2012 সালে GitHub-এর একজন Russian Developer Egor Homakov এই Vulnerability ব্যবহার করে GitHub-এর Public Key Modify করেছিলেন, যা GitHub-কে এই বিষয়ে ব্যাপক পরিবর্তন আনতে বাধ্য করেছিল।
OWASP API Security Top 10-এ Mass Assignment (API6:2019) এবং পরবর্তীতে এটি Broken Object Property Level Authorization (API3:2023)-এ Evolve হয়েছে, যা এর গুরুত্ব প্রমাণ করে। এই বিস্তৃত প্রবন্ধে আমরা Mass Assignment-এর মৌলিক ধারণা, বিভিন্ন Framework-এ এর প্রকাশ, বাস্তব Exploitation কৌশল, এবং Robust Defense Pattern নিয়ে আলোচনা করব।
Mass Assignment-এর মৌলিক ধারণা
Mass Assignment হলো এমন একটি Pattern যেখানে ব্যবহারকারীর Input (HTTP Request Body) সরাসরি একটি Object-এর একাধিক Property-তে Bind করা হয়। উদাহরণস্বরূপ, একটি User Registration Endpoint যেখানে JSON {"username": "alice", "email": "[email protected]", "password": "secret"} আসে, Framework এটিকে User Object-এ Map করে।
সমস্যা হয় যখন Object-এ এমন Property থাকে যা ব্যবহারকারী Set করার অধিকার রাখেন না। যেমন isAdmin, isVerified, accountBalance, role, userId। যদি Developer Strict Whitelisting না করেন এবং একজন আক্রমণকারী Request-এ {"username": "alice", "email": "[email protected]", "password": "secret", "isAdmin": true} পাঠায়, এবং Framework সব Field সরাসরি Bind করে, তাহলে ব্যবহারকারী Admin Privilege পেয়ে যায়।
এই সমস্যার মূল কারণ হলো Backend Model এবং User-Facing API-এর মধ্যে পার্থক্যের অভাব। Database Model-এ সব Field থাকে, কিন্তু সব Field ব্যবহারকারীর Modify করার মতো নয়। সঠিক Architecture-এ আলাদা DTO (Data Transfer Object) থাকে যা শুধু User-Settable Field অন্তর্ভুক্ত করে।
বাস্তব আক্রমণের উদাহরণ
GitHub-এর 2012 সালের ঘটনায় Egor Homakov Mass Assignment ব্যবহার করে নিজের Public SSH Key Rails on Rails Foundation Repository-তে Add করেছিলেন, যা তাকে Push Access দিয়েছিল। Rails-এর তখনকার Default Behavior-এ যেকোনো Attribute Mass Assign করা যেত। GitHub এই Incident-এর পরে Strong Parameter Pattern Enforce করেছিল।
আরেকটি বিখ্যাত উদাহরণ হলো একটি Famous Ride-Sharing App-এর Bug Bounty, যেখানে Bug Hunter একটি ব্যবহারকারীর Profile Update Endpoint-এ "balance" Field পাঠিয়ে নিজের Wallet-এ অর্থ যোগ করতে পেরেছিলেন। যদিও UI-তে Balance Field দেখানো হত না, Backend Model-এ এটি ছিল এবং কোনো Validation ছিল না।
E-commerce Application-এ Mass Assignment-এর মাধ্যমে Order-এর "totalAmount" Modify করা একটি সাধারণ Attack। ব্যবহারকারী Checkout-এর সময় Request-এ totalAmount Override করে দিয়ে কম দাম দিতে পারে। সঠিক Implementation-এ totalAmount Backend-এ Server-Side Calculate হওয়া উচিত।
User Profile Endpoint-এ Email Verification Bypass আরেকটি সাধারণ Pattern। আক্রমণকারী Profile Update Request-এ {"email": "[email protected]", "isEmailVerified": true} পাঠিয়ে একটি Unverified Email কে Verified হিসেবে Mark করতে পারে, যা Password Reset Flow-এর মাধ্যমে Account Takeover-এ পরিণত হতে পারে।
Ruby on Rails এবং Strong Parameters
Rails 4-এর আগে Mass Assignment Vulnerability Common ছিল। তখন attr_accessible এবং attr_protected ব্যবহার করে Model Level-এ Field Whitelisting করতে হত। কিন্তু Developer প্রায়ই এটি ভুলে যেত বা ভুলভাবে Configure করত।
Rails 4 থেকে Strong Parameters Pattern Introduce হয়েছে। এটি Controller-এ Filtering Enforce করে। উদাহরণ - params.require(:user).permit(:name, :email, :password)। এটি শুধু এই তিনটি Field Allow করে, অন্য কোনো Field পাঠালে Silently Ignore করে। isAdmin বা role Field Request-এ থাকলেও Bind হবে না।
Rails Community-তে এই Pattern এখন Universal Best Practice। তবে Custom JSON Parsing বা Active Model Serializer-এর সাথে কাজ করার সময় এই সুরক্ষা Bypass হতে পারে। প্রতিটি Endpoint-এর Permit Call পর্যালোচনা করা গুরুত্বপূর্ণ।
Nested Attributes-এর সাথে Mass Assignment আরও জটিল। যদি একটি User-এর Nested Address থাকে, তাহলে permit(:name, address_attributes: [:street, :city]) লিখতে হয়। ভুলে যদি address_attributes Permit করা হয় Whitelist ছাড়া, তাহলে Address-এর সব Field Mass Assignable হয়ে যায়।
Django এবং ModelForm
Django-তে ModelForm এবং Django REST Framework-এর ModelSerializer Mass Assignment-এর সবচেয়ে সাধারণ Vector। ModelSerializer-এ Meta Class-এ fields = 'all' লেখা একটি Common Anti-Pattern, যা সব Model Field-কে Read-Write করে।
সঠিক Pattern হলো fields-এ Explicitly List লেখা - fields = ['username', 'email', 'first_name']। অথবা exclude ব্যবহার করা, তবে Whitelist পদ্ধতি বেশি নিরাপদ কারণ নতুন Field যোগ হলে Default-এ Excluded থাকে না।
read_only_fields ব্যবহার করে নির্দিষ্ট Field-কে শুধু Output-এর জন্য Mark করা যায়। যেমন read_only_fields = ['id', 'is_staff', 'date_joined']। এই Field Request-এ এলেও Ignored হবে।
DRF-এর Generic View ব্যবহার করার সময় perform_create এবং perform_update Method Override করে Server-Side Field সঠিকভাবে Set করা উচিত। উদাহরণ - perform_create(self, serializer): serializer.save(user=self.request.user)। এতে user Field Always Current User-এ Set হয়, Request-এ Override সম্ভব নয়।
ASP.NET Core এবং Model Binding
ASP.NET Core-এ [FromBody] দিয়ে Model Binding হয়। Default-এ সব Public Property Bindable। [Bind("Name", "Email")] Attribute দিয়ে Specific Field-এ Restrict করা যায়, কিন্তু এটি প্রায়ই ভুলে যাওয়া হয়।
সঠিক Pattern হলো API-এর জন্য আলাদা DTO তৈরি করা। যেমন UserCreateDto, UserUpdateDto, এবং UserResponseDto। প্রতিটি Use Case-এর জন্য আলাদা DTO শুধু প্রয়োজনীয় Field Expose করে। AutoMapper বা Manual Mapping দিয়ে DTO থেকে Entity-তে Map করা হয়।
[BindNever] Attribute Sensitive Field-এ যুক্ত করা যায়, যাতে এই Property Binding-এর সময় Bind না হয়। যেমন Entity Model-এ public bool IsAdmin { get; set; }-এর উপরে [BindNever] দিলে এটি Request থেকে কখনো Set হবে না।
EF Core-এর Update Method DbContext.Entry(entity).State = EntityState.Modified করলে সব Property Update হয়। এর বদলে Selective Property Update করা উচিত - context.Entry(user).Property(u => u.Name).IsModified = true।
Spring Boot এবং @ModelAttribute
Spring Boot-এ @ModelAttribute বা @RequestBody-এর সাথে Mass Assignment Issue ঘটে। Default Behavior-এ সব Field Bind হয়। @InitBinder Method ব্যবহার করে binder.setDisallowedFields("isAdmin", "role") দিয়ে Specific Field Disallow করা যায়।
সবচেয়ে নিরাপদ Pattern হলো Java-এ Record বা Lombok-এর সাথে Immutable DTO তৈরি করা। API-এর প্রতিটি Endpoint-এর জন্য একটি Specific DTO Class, যার মধ্যে শুধু User-Settable Field। DTO থেকে Entity-তে Conversion MapStruct বা Manual Mapping দিয়ে।
Spring Data-এর Repository Layer Direct ব্যবহার করার সময় সতর্ক থাকা প্রয়োজন। save() Method সম্পূর্ণ Entity Update করে, যা Mass Assignment-এর মাধ্যমে Modified Field-গুলো Persist করতে পারে।
JPA-র @Column(updatable = false) এবং @Column(insertable = false) Annotation নির্দিষ্ট Field-কে Database Level-এ Protect করে। তবে এটি একটি Defense Layer মাত্র, Primary Defense Controller Level-এ থাকা উচিত।
GraphQL এবং Mass Assignment
GraphQL Mutation-এ Mass Assignment Vulnerability ভিন্ন রূপে আসে। Schema Definition Language বা SDL-এ Input Type Define করা হয়। যদি একটি Input Type Database Type-এর Mirror হয়, তাহলে Mass Assignment Risk থাকে।
সঠিক Pattern হলো প্রতিটি Mutation-এর জন্য নির্দিষ্ট Input Type তৈরি করা। UpdateUserProfileInput-এ শুধু name, bio, avatar Field থাকবে, isAdmin বা role থাকবে না। GraphQL-এর Strict Schema এই Discipline Enforce করে।
GraphQL Resolver-এ Authorization Check প্রতিটি Field-এর জন্য আলাদাভাবে করা উচিত। যেমন একজন Standard User শুধু নিজের Profile Update করতে পারে, একজন Admin অন্যদেরও পারে। শুধু Argument-Based Filtering যথেষ্ট নয়, Context-Based Authorization প্রয়োজন।
GraphQL-এর Introspection Query Production-এ Disable করা উচিত। Otherwise আক্রমণকারী Schema পড়ে দেখতে পারে কোন Field Available, যা Exploitation সহজ করে।
Automated Detection এবং Fuzzing
Mass Assignment Vulnerability Manual Testing-এ প্রায়ই Miss হয়। Automated Tool ব্যবহার করে Detection বাড়ানো যায়। Burp Suite-এর Param Miner Extension Unknown Parameter শনাক্ত করতে পারে।
Akto, APIClarity, এবং 42Crunch-এর মতো API Security Platform Mass Assignment-এর জন্য Specialized Test চালায়। তারা একটি Endpoint-এর Response-এ থাকা Field-গুলো Request-এ Submit করে এবং দেখে Server Response কীভাবে পরিবর্তন হয়।
Fuzzing-এর সময় Common Sensitive Field Name যেমন isAdmin, role, permissions, balance, status, verified, approved Test করা উচিত। OpenAPI Specification-এ Documented Field-এর বাইরের Field-গুলোও পরীক্ষা করা গুরুত্বপূর্ণ।
CI/CD Pipeline-এ Schemathesis-এর মতো Property-Based Testing Tool Integrate করা যায়। এটি OpenAPI Schema থেকে Test Case Generate করে এবং Mass Assignment সহ বিভিন্ন API Security Issue শনাক্ত করে।
Source Code Analysis
SAST Tool যেমন Semgrep, CodeQL, SonarQube, এবং Snyk Mass Assignment Pattern Detect করতে পারে। তারা Code-এ User Input থেকে Model-এ Direct Assignment-এর Pattern খুঁজে বের করে।
Custom Semgrep Rule লেখা যায় Specific Framework-এর জন্য। যেমন Rails-এ params.permit ছাড়া params সরাসরি update_attributes-এ পাঠানোর Pattern, বা Django-তে ModelSerializer-এ fields = 'all'-এর উপস্থিতি।
Code Review Checklist-এ Mass Assignment অন্তর্ভুক্ত করা উচিত। প্রতিটি API Endpoint-এর জন্য Reviewer-কে যাচাই করতে হবে - কোন Field User-Settable, কোন Field Server-Set, এবং Code এই পার্থক্য সঠিকভাবে Enforce করছে কিনা।
প্রতিরোধ ও প্রতিকার
Mass Assignment প্রতিরোধের সবচেয়ে নির্ভরযোগ্য পদ্ধতি হলো Allowlist Pattern - শুধু Explicitly Allowed Field-গুলো Bind করা। Denylist Approach কম নিরাপদ কারণ নতুন Field যোগ হলে সেগুলো Default-এ Allowed হয়ে যায়।
আলাদা DTO Pattern একটি Universal Solution। প্রতিটি API Endpoint-এর Input এবং Output-এর জন্য আলাদা DTO Class। Database Entity কখনো সরাসরি API-এ Expose না করা। Mapping Layer (AutoMapper, MapStruct, Manual) DTO এবং Entity-এর মধ্যে Translation করবে।
Server-Side Validation এবং Authorization-এর মধ্যে পার্থক্য বোঝা গুরুত্বপূর্ণ। Mass Assignment একটি Authorization Issue - User কোন Field Modify করতে পারবে তা নির্ধারণ। শুধু Format Validation যথেষ্ট নয়, Field-Level Permission Check প্রয়োজন।
Audit Logging - সব Critical Field Change Log করা। যদি isAdmin, role, বা balance পরিবর্তিত হয়, তা Audit Log-এ থাকা উচিত। Anomaly Detection এই Log-এ Suspicious Pattern শনাক্ত করতে পারে।
API Documentation-এ প্রতিটি Field-এর জন্য স্পষ্ট করা - এটি User-Settable, Server-Set, বা Admin-Only। OpenAPI Specification-এ readOnly: true Property সঠিকভাবে ব্যবহার করা।
Regular Security Testing - বছরে অন্তত একবার Penetration Test যেখানে Mass Assignment-এর জন্য Specific Test থাকবে। Bug Bounty Program-এ এই Vulnerability Class Documented থাকবে।
Mass Assignment একটি Subtle কিন্তু বিধ্বংসী Web Application Vulnerability, যা Productivity-Focused Framework-গুলোর Side Effect। GitHub, Ride-Sharing App, এবং অসংখ্য E-commerce Platform-এ এই Vulnerability-র Exploitation প্রমাণ করেছে এর গুরুত্ব। OWASP API Security Top 10-এ এটি Broken Object Property Level Authorization হিসেবে Evolve হয়েছে, যা Modern API-এর Reality-কে Reflect করে। প্রতিরোধের জন্য Allowlist Pattern, আলাদা DTO, এবং Server-Side Field Authorization অপরিহার্য। Developer Training, Code Review Checklist, SAST Integration, এবং নিয়মিত Penetration Testing-এর সমন্বয়ে এই Vulnerability Class কে কার্যকরভাবে Address করা সম্ভব। Modern API-Driven Application-এ Mass Assignment Defense একটি Foundational Requirement।
আপনার জ্ঞান যাচাই করতে প্রস্তুত? আজই HackCert-এ Mass Assignment MCQ Quiz-টি দিন!