nerdexam
CompTIA

CAS-002 · Question #805

A penetration tester is inspecting traffic on a new mobile banking application and sends the following web request: Content-type: application/json { "account": [ { "creditAccount":"Credit Card…

The correct answer is A. Missing input validation on some fields C. Sensitive details communicated in clear-text. The API response exposes full card details (PAN, expiry, CVV) in plaintext and the request lacks evidence of input validation, representing two distinct OWASP API security weaknesses.

Enterprise Security

Question

A penetration tester is inspecting traffic on a new mobile banking application and sends the following web request:

Content-type: application/json { "account":

[ { "creditAccount":"Credit Card Rewards account"} { ], "customer":

[ { "name":"Joe Citizen"} { "custRef":"3153151"} ] } The banking website responds with:

HTTP/1.1 200 OK { "newAccountDetails":

[ { "cardNumber":"1234123412341234"} { "cardExpiry":"2020-12-31"} { "cardCVV":"909"} ], "marketingCookieTracker":"JSESSIONID=000000001" "returnCode":"Account added successfully" } Which of the following are security weaknesses in this example? (Select TWO).

Options

  • AMissing input validation on some fields
  • BVulnerable to SQL injection
  • CSensitive details communicated in clear-text
  • DVulnerable to XSS
  • EVulnerable to malware file uploads
  • FJSON/REST is not as secure as XML

How the community answered

(31 responses)
  • A
    55% (17)
  • B
    6% (2)
  • D
    26% (8)
  • E
    10% (3)
  • F
    3% (1)

Why each option

The API response exposes full card details (PAN, expiry, CVV) in plaintext and the request lacks evidence of input validation, representing two distinct OWASP API security weaknesses.

AMissing input validation on some fieldsCorrect

The request body adds a credit account without any apparent server-side input validation on fields such as account type or customer reference, which could allow malformed or malicious data to be processed and stored, a violation of OWASP API3 (Excessive Data Exposure) and input handling best practices.

BVulnerable to SQL injection

SQL injection attacks target database query construction through user-supplied input, but the interaction shown is a JSON/REST API with no indication of raw SQL being constructed from the request parameters.

CSensitive details communicated in clear-textCorrect

The server response returns the full card number, expiry date, and CVV in the JSON body without any masking or tokenization, transmitting sensitive payment card data in cleartext within the application layer - this violates PCI-DSS requirements and OWASP API3, as this data should never be returned in full to the client.

DVulnerable to XSS

Cross-Site Scripting (XSS) requires a browser to render and execute injected scripts in an HTML context - this API returns JSON to a mobile application, so there is no browser DOM rendering path for XSS to occur.

EVulnerable to malware file uploads

The request involves structured JSON data for account creation, not file upload functionality, so malware file upload vulnerabilities are not applicable to this interaction.

FJSON/REST is not as secure as XML

JSON/REST and XML/SOAP are both transport-layer agnostic formats and can be equally secure or insecure depending on implementation - the format itself does not determine the security level.

Concept tested: API security - sensitive data exposure and input validation

Source: https://owasp.org/www-project-api-security/

Topics

#API security#mobile banking#sensitive data exposure#REST security

Community Discussion

No community discussion yet for this question.

Sign up to join the discussion
Full CAS-002 Practice