# SOAP Credentials Security Test Plan

## Context
- **Credit Card credential**: Used for first tariff estimate
- **Account credential**: Used for guest estimate
- **Platform feature**: Corporate customers (Stryker, J&J, NCR) use PMA for shipping
- **API Portal**: Customers register their account to platform to get keys

## Security Concern
Credentials are **hardcoded in APK** and can be extracted by any attacker with basic reverse engineering skills.

## Proposed Testing (Work with PMA/EWS Team)

### Test 1: Rate Limiting Verification
**Purpose**: Verify rate limits prevent abuse of extracted credentials

**Method**:
```python
import requests
import time

# Test rate limiting on estimate endpoint
url = "https://webservices.purolator.com/EWS/v2/Estimating/EstimatingService.asmx"
headers = {
    "Authorization": "Basic ZWY3NDc1ZWY3MGI0NGY0Njg3MTU4ZmJiYjlmZjNmNDc6fEhYWTIpLjY=",  # Account
    "Content-Type": "text/xml; charset=utf-8",
    "SOAPAction": "http://purolator.com/pws/service/v2/GetQuickEstimate"
}

# Try 100 requests in rapid succession
for i in range(100):
    response = requests.post(url, headers=headers, data=SOAP_ENVELOPE)
    print(f"Request {i}: Status {response.status_code}")
    if response.status_code == 429:  # Rate limited
        print("✓ Rate limiting active")
        break
    time.sleep(0.1)
```

### Test 2: Account Association Validation
**Purpose**: Verify credentials alone cannot access customer data without valid account number

**Questions for PMA/EWS**:
- Do these credentials allow **any** account number to be used in SOAP requests?
- Or must the account number be pre-registered in API Portal?
- What happens if attacker tries random account numbers?

**Test Request**:
```xml
<soap:Envelope>
  <soap:Body>
    <GetQuickEstimateRequest>
      <BillingAccountNumber>UNKNOWN_ACCOUNT_123</BillingAccountNumber>
      <SenderPostalCode>K1A 0B1</SenderPostalCode>
      <ReceiverPostalCode>M5H 2N2</ReceiverPostalCode>
      <Weight><Value>1</Value><WeightUnit>lb</WeightUnit></Weight>
    </GetQuickEstimateRequest>
  </soap:Body>
</soap:Envelope>
```

**Expected secure behavior**:
- Request fails without valid registered account number
- Credentials alone are insufficient

### Test 3: Logging and Monitoring
**Purpose**: Verify suspicious activity is logged

**Questions for Team**:
- Are API calls from these credentials logged with:
  - Source IP address?
  - Request frequency?
  - Account numbers attempted?
- Are there alerts for unusual patterns?

### Test 4: Client Certificate Validation
**Purpose**: Understand why POC failed with AWS Sig v4 error

**Question**: Does the SOAP endpoint require:
- TLS client certificates from mobile app?
- Specific TLS fingerprint?
- AWS Sig v4 signing from untrusted sources?

**Our observation**: App code sends **only Basic Auth**, but external test got AWS error

### Test 5: Credential Rotation
**Purpose**: Verify credentials can be rotated without app update

**Questions**:
- Can these credentials be rotated server-side?
- Or does rotation require new app release?
- What's the rotation schedule?

## Security Recommendations

### Immediate
1. ✅ **Rate limiting** on estimate endpoints (prevent abuse)
2. ✅ **Account validation** (credentials alone insufficient)
3. ✅ **IP allow-listing** for known mobile app IP ranges
4. ✅ **Logging** of all requests with these credentials

### Short-term
1. 🔄 **Move credentials to Firebase Remote Config**
   - Still retrievable but can be rotated without app update
   - Add integrity checks (SafetyNet/Play Integrity)

2. 🔄 **Certificate pinning validation**
   - Ensure server validates expected mobile client certificates
   - Block requests without proper TLS fingerprint

### Long-term (Recommended)
1. 🔒 **Device-specific tokens**
   - Generate unique token per app install
   - Associate with device fingerprint + SafetyNet attestation
   - Revoke individual devices if compromised

2. 🔒 **OAuth 2.0 Client Credentials Flow**
   - Replace Basic Auth with OAuth tokens
   - Short-lived tokens (1 hour)
   - Server-side rotation capability

3. 🔒 **API Gateway with device validation**
   - Require SafetyNet/Play Integrity attestation
   - Validate app signature
   - Block rooted/tampered devices

## Risk Assessment

**Current Risk Level**: **MEDIUM**

**Why not HIGH**:
- Credentials are for platform features, not direct customer data access
- Likely protected by account number validation
- Server may require TLS client certificates (explains AWS error)

**Why not LOW**:
- Credentials ARE extractable from APK
- Basic Auth is permanent (no expiry)
- No per-device security
- Attacker with valid account numbers could abuse

**Exploitation Scenario**:
1. Attacker extracts credentials from APK (✓ proven)
2. Attacker obtains valid corporate account numbers (social engineering, data breach, etc.)
3. Attacker uses credentials + account numbers to:
   - Create shipments on corporate accounts
   - Void legitimate shipments
   - Generate shipping labels
   - Conduct shipping fraud

**Mitigation**: Account validation and rate limiting reduce risk significantly

## Testing Checklist

- [ ] Verify rate limiting on estimate endpoints
- [ ] Test with invalid account numbers (should fail)
- [ ] Confirm logging captures source IP and patterns
- [ ] Understand client certificate requirements
- [ ] Test credential rotation capability
- [ ] Review API Portal account registration flow
- [ ] Verify corporate customer isolation (can't access each other's data)
- [ ] Test SafetyNet/Play Integrity integration (if exists)

## Report to Security Team

**Subject**: SOAP API Credentials Hardcoded in Mobile APK

**Summary**:
Platform credentials for corporate shipping features are hardcoded in the Purolator Mobile APK and can be extracted through standard reverse engineering.

**Location**:
- File: `com/purolator/mobileapp/utils/security/X.java` line 77
- Usage: `PurolatorApplication.java` line 301
- Operations: Tariff estimates, guest estimates, corporate shipping

**Evidence**:
- Account credential: `ef7475ef70b44f4687158fbbb9ff3f47:|HXY2).6`
- Credit Card credential: `000b94d6601f4c96ba75d84433 17a2a9:xyA}FWoD`
- Endpoint: `https://webservices.purolator.com/EWS/v2/Shipping/ShippingService.asmx`

**Impact**:
While credentials are for platform features (not direct data access), they could be abused if combined with valid corporate account numbers.

**Recommended Testing**:
Work with PMA/EWS team to verify:
1. Rate limiting effectiveness
2. Account number validation
3. Logging and monitoring
4. Client certificate requirements
5. Credential rotation capability

**Recommended Mitigations**:
1. Short-term: Verify rate limiting and account validation
2. Medium-term: Move to Firebase Remote Config with rotation
3. Long-term: Implement device-specific tokens with SafetyNet attestation