Skip to content

08-server-side.md

Latest commit

 

History

History
124 lines (88 loc) · 3.66 KB

08-server-side.md

File metadata and controls

124 lines (88 loc) · 3.66 KB
Raw

08 — Server-Side

Most mobile bugs are API bugs. The app is just the delivery mechanism.

Mindset shift

Don't test "the mobile app." Test the API the mobile app talks to, with the mobile app's credentials and context. Mobile APIs often have weaker protections than web APIs because:

  • They're assumed to be called only by the official app.
  • They expose mobile-specific endpoints (/api/v2/mobile/...) that lag behind web security patches.
  • They trust device fingerprints, app signatures, or hardcoded API keys.

API discovery from mobile

Extract endpoints from binary

# iOS strings
strings -a App | grep -E 'https?://.*api'
strings -a App | grep -E '/api/v[0-9]+'

# Android strings
apktool d app.apk
grep -riE 'https?://.*api' app_decompiled/res/ app_decompiled/smali/

Proxy all traffic

  • Launch every feature in the app while Burp is intercepting.
  • Background refresh, push notification actions, and widget updates all trigger API calls.
  • Look for admin/debug endpoints not exposed in the UI (/api/debug/, /internal/).

Mobile-specific API attacks

Hardcoded API keys

# Search for keys in binary
grep -riE 'api[_-]?key.*[=:]' app_decompiled/
grep -riE 'x-api-key' app_decompiled/

If found:

  • Does the key have rate limits?
  • Does it grant access to admin endpoints?
  • Is it the same key used across iOS and Android?

Device fingerprint bypass

Some APIs validate X-Device-ID, X-App-Version, or custom signatures.

# Replay request with modified device ID
curl -H "X-Device-ID: attacker-device" \
     -H "Authorization: Bearer $TOKEN" \
     https://$TARGET/api/mobile/profile

Certificate pinning (server-side check)

If the server expects a pinned client certificate (mTLS):

  • Extract the client cert from the app binary (look for .p12, .pem, .der).
  • Use it with curl: curl --cert client.pem --key client.key https://$TARGET/

Push notification abuse

  • Can you send arbitrary push notifications via the API?
  • POST /api/push/send with another user's device token?
  • Push payloads that deep-link to sensitive actions?

IDOR in mobile context

Mobile apps often cache user lists, group memberships, or location data.

# Common mobile IDOR patterns
GET /api/v2/users/me           → try /users/12345
GET /api/v2/groups/123/members → try /groups/124/members
GET /api/v2/location/history   → try with other user's token

GraphQL / Firebase / Backend-as-a-Service

Firebase

# If firebaseio.com URL is in strings:
curl https://<project>.firebaseio.com/.json
# If unsecured → full database read/write

GraphQL

# Introspection often enabled on mobile endpoints
curl https://$TARGET/graphql \
  -H "Content-Type: application/json" \
  -d '{"query": "{ __schema { types { name } } }"}'

AWS S3 / Cloud buckets

# Extract bucket names from strings
grep -ri "s3.amazonaws.com\|storage.googleapis.com" strings.txt
# Test with: aws s3 ls s3://bucket-name/ --no-sign-request

Rate limiting

Mobile APIs often have per-device rate limits that are weaker than per-user limits.

  • Rotate X-Device-ID headers.
  • Test whether limits are IP-based (use multiple egress points).

What gets missed

  • Older API versions (/v1/, /beta/) still active and less secure.
  • Internal endpoints exposed to mobile apps but not web (/api/mobile/admin/).
  • Server-side rendering (SSR) endpoints that accept mobile deeplink URLs.
  • Analytics / crash reporting endpoints that receive PII without consent.

Don't bother

  • Reporting "API key is hardcoded" as Critical unless it grants admin/sensitive access.
  • Testing for SQLi with generic payloads before understanding the ORM/framework.