I85PREP
⌘ K
CISP-PTS study materials
CISP-PTS study resources

CISP-PTS practice questions

One question at a time. Build your CISP-PTS understanding.

First 50 of 190 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Web application and data-protection foundations

During a PTS-level web review, a REST create endpoint returns HTTP 200 with an empty body after inserting a row. Which status best matches HTTP semantics for a successful create that also returns a locator for the new resource?

  1. 202 Accepted because the insert is persisted
  2. 201 Created with a Location header Correct answer.
  3. 204 No Content because the body is empty
  4. 302 Found so the client re-GETs the new object

Explanation

201Created directly describes successful creation and can identify the primary new resource with Location.204means successful fulfillment with no response content and is not restricted to existing-resource operations.202indicates acceptance rather than completed processing, while302is a redirect. The supplied successful-create-with-locator scenario therefore fits201.

Question 2Web application and data-protection foundations

A session cookie is readable from document.cookie in a victim browser even though the application already uses HTTPS. Which cookie attribute is the primary control to stop that JavaScript access?

  1. SameSite=Strict
  2. HttpOnly Correct answer.
  3. Path=/
  4. Secure

Explanation

HttpOnly instructs the browser not to expose the cookie to JavaScript APIs such as document.cookie, which reduces the impact of XSS on session theft. Secure only requires HTTPS when sending the cookie. SameSite restricts cross-site sending, which is a CSRF control. Path limits which URLs receive the cookie; it is not an XSS control.

Question 3Web application and data-protection foundations

A comment field stores a script that later executes in every moderator's browser when they open the queue. Which XSS class is this?

  1. Stored XSS Correct answer.
  2. DOM-based XSS with no server persistence
  3. Mutation XSS that only exists after HTML rewriting
  4. Reflected XSS

Explanation

Stored (persistent) XSS is saved on the server and replayed to other users. That matches a comment queue that infects every moderator who loads the stored content. Reflected XSS is echoed in the immediate response to the submitter. DOM XSS is a client-side source-to-sink flow and need not persist. Mutation XSS is a special case of browser HTML rewriting, not the primary class here.

Question 4Web application and data-protection foundations

Which condition is the core prerequisite for classic cookie-based CSRF against a state-changing request?

  1. The victim has no session and the attacker supplies a stolen refresh token in the URL
  2. The browser automatically attaches first-party cookies on a cross-site request that the server treats as authenticated Correct answer.
  3. The target API requires a custom Authorization header that JavaScript must set
  4. CORS is disabled on the target origin

Explanation

Classic CSRF abuses the browser's habit of attaching cookies to requests the attacker can trigger (form POST, some image/fetch modes) while the server still treats those cookies as proof of intent. Custom Authorization headers are not sent automatically, which is why bearer-token APIs are not CSRF'd the same way. CORS governs reading cross-origin responses, not whether a cookie-authenticated POST can fire. A stolen token in a URL is credential theft or session fixation, not CSRF.

Question 5Web application and data-protection foundations

Which coding pattern is the primary cause of SQL injection in application queries?

  1. Using a connection pool that reuses TCP sessions
  2. Storing passwords with a slow adaptive hash
  3. Enabling TLS on the database port
  4. Building the SQL statement by concatenating or interpolating attacker-influenced strings into the query text Correct answer.

Explanation

SQL injection happens when untrusted data changes the SQL statement's structure instead of remaining data. Concatenation and string interpolation into query text are the usual root cause. Connection pooling, password hashing, and TLS are important but orthogonal. Parameterized queries (prepared statements with bound parameters) keep data out of the statement structure.

Question 6Web application and data-protection foundations

A registration form stores a profile 'nickname' without executing SQL. Weeks later, an admin report concatenates that nickname into a SELECT and dumps extra tables. What class is this?

  1. Insecure direct object reference to the nickname column
  2. Reflected XSS in the admin UI
  3. Second-order SQL injection Correct answer.
  4. CSRF against the registration form

Explanation

Second-order SQL injection stores a payload in one step and triggers it later when a different query interpolates the stored value. That matches a nickname that is inert at registration and dangerous only in the admin report. XSS would execute in a browser. CSRF would forge a state change with the victim's cookies. IDOR is an access-control issue on object identifiers, not query composition.

Question 7Web application and data-protection foundations

An XML upload feature parses documents with a fully featured DTD processor and external-entity resolution enabled. Which outcome is the defining XXE impact class?

  1. The browser executes the XML as JavaScript because of MIME sniffing
  2. The application switches from UTF-8 to UTF-7 and disables CSRF tokens
  3. The parser resolves attacker-supplied external entities, which can disclose local files or force the server to fetch URLs Correct answer.
  4. The XML is automatically treated as JSON and bypasses schema validation

Explanation

XML External Entity (XXE) processing lets a document define entities that the parser fetches or expands. That can leak files, cause denial of service via entity expansion, or turn the parser into an SSRF client. XML is not silently reinterpreted as JSON. Browser XSS via MIME sniffing is a different bug class. Character-set tricks are not the XXE definition.

Question 8Web application and data-protection foundations

A server-side PDF renderer accepts a user-supplied URL and fetches it from the application host. Blocking literal IP literals in 169.254.169.254 is the only control. Why is that insufficient against SSRF?

  1. DNS rebinding, redirects, alternate encodings, or attacker-controlled names can still cause the server to reach internal or metadata endpoints Correct answer.
  2. SSRF only works if the PDF renderer runs as root
  3. Browsers will not follow the rendered PDF, so the finding is not exploitable
  4. Cloud metadata endpoints ignore HTTP requests that lack a Host header

Explanation

SSRF is a server-side fetch under attacker influence. Hostname allow/deny lists fail when DNS answers change (rebinding), when HTTP redirects hop to another address, or when equivalent URL forms bypass a naive string filter. Privilege of the renderer affects impact, not existence. The victim of SSRF is the server, not the browser. Metadata services are designed to answer local HTTP clients.

Question 9Web application and data-protection foundations

Which CSRF defense combination is the most robust for a cookie-authenticated browser application?

  1. Switching all forms from POST to GET so tokens are not required
  2. Synchronizer (or double-submit) CSRF tokens plus SameSite cookies plus verifying Origin or Referer on state-changing requests Correct answer.
  3. Access-Control-Allow-Origin: * together with Access-Control-Allow-Credentials: true
  4. Relying only on a hidden field that never rotates and is copied into every cached page

Explanation

Defense in depth for CSRF is a per-session unguessable token bound to the user, cookie SameSite restrictions, and Origin/Referer checks on mutations. ACAO * with credentials is an invalid/dangerous CORS combination and does not authenticate intent. Static tokens in cacheable pages leak. GET mutations increase CSRF and cache risk.

Question 10Web application and data-protection foundations

Which file-upload control set actually reduces web-shell risk rather than trusting attacker-controlled metadata?

  1. Save uploads into the application directory using the original filename so links stay pretty
  2. Validate file magic bytes, allowlist extensions, store outside the web root with randomized names, and serve with a non-executable content type Correct answer.
  3. Trust Content-Type because browsers set it honestly
  4. Allow any extension if the filename contains only ASCII

Explanation

Content-Type and filenames are attacker-controlled. Real controls are content sniffing (magic bytes), a tight extension allowlist, storage outside executable web roots, unpredictable names, and serving with a safe MIME type (and no script execution). Pretty original names in the web root are a classic web-shell pattern.

Question 11Web application and data-protection foundations

Changing /api/invoices/4122 to /api/invoices/4123 returns another customer's invoice while remaining a normal user. What is the best name for this access-control failure?

  1. Insecure direct object reference (horizontal IDOR) Correct answer.
  2. CSRF because the request used a cookie
  3. Stored XSS in the invoice PDF
  4. Vertical privilege escalation to administrator

Explanation

Horizontal IDOR is accessing another principal's object by manipulating an identifier without a server-side authorization check. Vertical escalation would grant a higher role (admin). Cookie use does not make it CSRF. XSS would be script injection, not unauthorized record access.

Question 12Web application and data-protection foundations

An attacker sets a victim's session identifier before login (for example via a crafted URL or cookie), the victim authenticates, and the identifier does not change. What vulnerability is this?

  1. Open redirect
  2. Clickjacking
  3. Session fixation Correct answer.
  4. JWT algorithm none

Explanation

Session fixation is authenticating a victim into a session ID the attacker already knows because the server failed to rotate the identifier at login. JWT alg=none is a token-integrity issue. Open redirect is an unvalidated jump. Clickjacking is UI redressing. The durable fix is to issue a new session ID on privilege change (login).

Question 13Web application and data-protection foundations

A JSON Web Token API accepts the header algorithm value without pinning an expected algorithm, and the verification key material can be confused between HMAC secrets and asymmetric public keys. What is the integrity failure?

  1. Algorithm confusion / unpinned alg, so an attacker can pick a weaker or mismatched verification mode Correct answer.
  2. HttpOnly missing on a cookie that does not store the JWT
  3. SameSite=Lax blocking first-party navigation
  4. TLS 1.2 being used instead of TLS 1.3

Explanation

JWT libraries that trust the token's alg field can be tricked into verifying with the wrong primitive (for example treating an RSA public key as an HMAC secret, or accepting a none-like unsigned token). The fix is to pin the allowed algorithm server-side and use key IDs from a controlled set. Cookie flags and TLS versions are separate controls.

Question 14Web application and data-protection foundations

A reverse proxy and an origin server disagree on whether Content-Length or Transfer-Encoding defines the HTTP request body boundary. What class of issue should a PTS tester look for?

  1. HTTP request smuggling / desynchronization Correct answer.
  2. Classic reflected XSS in the proxy error page only
  3. BGP prefix hijacking
  4. ARP spoofing on the tester laptop

Explanation

Request smuggling (HTTP desync) happens when two HTTP processors parse one TCP stream into different logical requests, usually via CL vs TE disagreements or malformed transfer-encoding. That can poison caches, bypass front-end ACLs, or append requests onto other users. XSS, BGP, and ARP are different layers.

Question 15Web application and data-protection foundations

A single-page app copies location.hash into innerHTML with no encoding. The server HTML is static and has a strict CSP that still allows 'unsafe-inline'. Which XSS class is this?

  1. Stored XSS in the database
  2. SQL injection via the hash fragment
  3. CSRF against the hashchange handler
  4. DOM-based XSS Correct answer.

Explanation

DOM XSS is a client-side flow from a source (here location.hash) to a dangerous sink (innerHTML). The fragment is not sent to the server, so stored XSS and SQL injection do not apply. CSRF is about forged authenticated requests, not DOM sinks. unsafe-inline in CSP largely disables script CSP as a mitigation.

Question 16Web application and data-protection foundations

A PHP include uses a user-controlled path, allow_url_include is Off, and the tester can only reach files already on the host. Which finding is accurate?

  1. Local file inclusion (LFI), which may still disclose source or configuration if path traversal is possible Correct answer.
  2. Remote file inclusion (RFI) because any path parameter is remote by definition
  3. XXE because PHP include parses XML
  4. SSRF because include always opens a TCP connection

Explanation

LFI includes a local file path under attacker influence. RFI requires the include of a remote URL, which typically needs allow_url_include (or an equivalent wrapper). PHP include is not XML parsing (XXE) and does not always create an outbound TCP fetch. Path traversal plus LFI can still leak php files, logs, or keys.

Question 17Web application and data-protection foundations

A diagnostic endpoint passes a hostname argument to an OS shell helper instead of a dedicated DNS API. Output is not returned, but response time varies with input. What is the most accurate classification?

  1. SQL injection because time delays always mean database WAITFOR
  2. Stored XSS in the hostname field
  3. CSRF that does not need a vulnerable parameter
  4. Blind OS command injection Correct answer.

Explanation

When untrusted input reaches a shell or command interpreter, that is OS command injection. If results are not echoed, timing or out-of-band channels make it blind. Time delays are not unique to SQL. XSS would execute in a browser. CSRF is a separate request-forgery class.

Question 18Web application and data-protection foundations

A Content-Security-Policy uses script-src 'self' https://cdn.example.net plus 'unsafe-inline'. Why is this a weak XSS mitigation?

  1. Nonces are required by HTTP/2, so the policy is invalid
  2. 'unsafe-inline' allows inline scripts, so CSP will not block typical reflected or stored script tags Correct answer.
  3. CSP can never apply to HTTPS pages
  4. 'self' always includes every subdomain of the public suffix

Explanation

script-src 'unsafe-inline' permits inline <script> and many inline event handlers, which is exactly how most XSS payloads run. Host allowlists also fail if a JSONP or Angular-style gadget exists on an allowed origin. CSP works on HTTPS. 'self' is the origin, not the entire eTLD. Nonces are optional and unrelated to HTTP/2 validity.

Question 19Web application and data-protection foundations

Password-reset emails build the link host from the HTTP Host header without validation. What is the primary risk?

  1. SSRF to cloud metadata because Host is a URL
  2. SQL injection in the Host header always reaches the database driver
  3. Clickjacking of the email client
  4. Host-header poisoning that can turn reset links into attacker-controlled URLs Correct answer.

Explanation

If absolute URLs in emails or caches use an untrusted Host header, an attacker can cause password-reset or cache keys to point at a domain they control (credential theft or cache poisoning). Host is not a fetch URL by itself (SSRF). Host is rarely bound into SQL. Clickjacking is a framing issue, not email-link generation.

Question 20Web application and data-protection foundations

Which HTTP method is defined as safe and should not change server state, making it a poor choice for 'delete user' if a browser or crawler may replay it?

  1. POST
  2. PUT
  3. PATCH
  4. GET Correct answer.

Explanation

GET (and HEAD) are safe methods: they should not have side effects beyond retrieval. Using GET for deletes invites CSRF via <img>, prefetch, and crawlers. POST, PUT, and PATCH are not safe methods; they are intended for state changes (with CSRF controls still required for cookie auth).

Question 21Web application and data-protection foundations

A Node.js service recursively merges user JSON into a shared options object. Setting __proto__ or constructor.prototype keys changes Object.prototype for later requests. What is this class?

  1. Prototype pollution Correct answer.
  2. Java insecure deserialization of ObjectInputStream
  3. CSS injection
  4. HTTP request smuggling

Explanation

Prototype pollution is a JavaScript inheritance-chain issue: attacker keys like __proto__ pollute Object.prototype so later code sees unexpected properties (often leading to RCE gadgets or auth bypasses in specific apps). Java ObjectInputStream is a different language's deserialization. CSS injection and request smuggling are unrelated parsers.

Question 22Web application and data-protection foundations

Submitting ${7*7} in a search box returns 49 in a server-rendered page, and the app uses a template engine. Which class should you report?

  1. DOM XSS only, because math ran in the browser
  2. CSRF because a form was used
  3. XXE because ${} is an XML entity
  4. Server-side template injection (SSTI) Correct answer.

Explanation

SSTI is untrusted input being interpreted as template code by a server-side engine. Arithmetic evaluation in the response is a classic confirmation that the template ran. It is not merely browser DOM XSS, not CSRF, and ${} is not an XML entity. Impact ranges from XSS to server-side code execution depending on the engine.

Question 23Web application and data-protection foundations

In a Java code review, request.getParameter("cmd") flows into Runtime.getRuntime().exec(...) with no allowlist or escaping API. What is the correct audit conclusion?

  1. Safe because Java cannot invoke the OS
  2. Only a logging issue because exec always discards output
  3. Automatically mitigated by using HTTPS
  4. A source-to-sink command-injection flaw: untrusted HTTP input reaches an OS command API without a sanitizer Correct answer.

Explanation

Code analysis for PTS is source → sanitizer → sink reasoning. HttpServletRequest parameters are a source; Runtime.exec / ProcessBuilder are OS command sinks. Missing sanitizer/allowlist is a high-confidence finding. Java can invoke the OS. TLS and discarded stdout do not remove the injection.

Question 24Web application and data-protection foundations

Which statement about preventing SQL injection is correct?

  1. A WAF signature feed replaces secure query APIs
  2. ORM use guarantees that raw SQL and concatenation never occur
  3. Bound parameters / prepared statements keep untrusted values out of the SQL grammar; escaping and WAF rules are not equivalent primary controls Correct answer.
  4. Escaping quotes once at the reverse proxy is sufficient for all databases

Explanation

Prepared statements with bound parameters (or equivalent bind APIs) are the primary control. Escaping is dialect-specific and easy to get wrong. WAFs are compensating controls. ORMs still allow raw SQL and unsafe interpolation. Stored procedures are safe only if they also bind parameters internally.

Question 25Web application and data-protection foundations

An API reflects the request Origin into Access-Control-Allow-Origin and also sends Access-Control-Allow-Credentials: true. What is the confidentiality issue?

  1. Cookies will never be sent on cross-site requests
  2. The browser ignores ACAO when credentials are true, so there is no issue
  3. Any attacker origin can read authenticated responses from the victim's browser Correct answer.
  4. CSRF tokens become unnecessary because CORS blocks all POSTs

Explanation

Reflecting arbitrary Origins with credentials tells the browser it may expose authenticated responses to attacker JavaScript. That is a cross-origin data leak. CORS does not replace CSRF tokens for simple cookie POSTs. Credentialed cross-site requests can still include cookies. Browsers allow a specific (non-wildcard) ACAO with credentials - and a reflected attacker origin is specific.

Question 26Web application and data-protection foundations

A CDN caches pages using only the URL path as the cache key, while the origin builds absolute links from an unkeyed X-Forwarded-Host header. What should you report?

  1. Only a client-side open redirect that cannot affect other users
  2. SQL injection in the CDN edge
  3. HSTS preload failure
  4. Web cache poisoning: an attacker can store a response that other users later receive Correct answer.

Explanation

Cache poisoning occurs when an unkeyed input (header, cookie, or similar) changes a cacheable response. Later users get the poisoned object (often with attacker URLs). That is more than a one-off redirect. SQL and HSTS are unrelated.

Question 27Web application and data-protection foundations

Which header pair is the correct framing defense against clickjacking of a sensitive page?

  1. Cache-Control: no-store alone
  2. Content-Security-Policy frame-ancestors 'none' (or X-Frame-Options DENY / SAMEORIGIN as legacy) Correct answer.
  3. SameSite=Strict alone with no framing policy
  4. Access-Control-Allow-Origin: 'none'

Explanation

Clickjacking is framing. CSP frame-ancestors is the modern control; X-Frame-Options DENY or SAMEORIGIN is the legacy equivalent. SameSite restricts cookie sending, not framing of a page the victim is already viewing as first-party. CORS and cache headers do not prevent UI redressing.

Question 28Web application and data-protection foundations

Apache Options Indexes is enabled on a document root that contains backup archives. What is the immediate issue?

  1. Indexes converts the site to PUT-writable WebDAV
  2. Directory listing can disclose files that were never meant to have URLs Correct answer.
  3. Indexes automatically enables CGI script execution
  4. Indexes forces TLS 1.0

Explanation

Directory listing (Indexes) reveals filenames so testers and attackers can fetch backups, .git remnants, or copies that had no public link. It does not by itself enable CGI, downgrade TLS, or turn on WebDAV PUT.

Question 29Web application and data-protection foundations

A login page takes next= and redirects with a 302 to any scheme/host. The OAuth client later reuses the same helper for redirect_uri handling. What is the primary risk?

  1. XXE in the Location header
  2. Command injection in the browser URL bar
  3. Open redirect that can steal OAuth codes/tokens or enable phishing with a trusted domain as the first hop Correct answer.
  4. SQL injection because 302 responses execute SQL

Explanation

Unvalidated redirects are phishing helpers and, when mixed with OAuth redirect_uri or token fragments, can leak authorization codes or tokens to an attacker origin. 302 is not SQL or XML parsing. The browser URL bar is not an OS command sink.

Question 30Web application and data-protection foundations

A Java API uses Jackson default typing (or a polymorphic type field) taken from client JSON to select the class to instantiate. Why is this a specialist-level finding even without a working gadget chain in the report?

  1. Attacker-controlled type discriminators plus available gadgets are insecure deserialization: the object graph can run unexpected constructors/setters Correct answer.
  2. JSON cannot instantiate classes in any JVM
  3. Default typing is only a performance flag
  4. The issue is identical to missing HttpOnly and should be scored as XSS

Explanation

Insecure deserialization is reconstructing an object graph from untrusted data with attacker-influenced types. Jackson default typing, Java native serialization, PHP unserialize, and Python pickle are instances of the same class. You report the unsafe pattern and reachable gadget conditions; you do not need to ship a weaponized chain. JSON mapping without polymorphic type control is ordinary databinding, not this issue.

Question 31Host and middleware hardening foundations

Which Apache pair reduces information leakage from Server banners without changing application logic?

  1. KeepAlive Off and Timeout 3600
  2. ServerTokens Prod and ServerSignature Off Correct answer.
  3. AllowOverride All and Options All
  4. TraceEnable On and EnableSendfile Off

Explanation

ServerTokens Prod emits a minimal Server header (product only). ServerSignature Off removes version footers on error pages. That is banner minimization. AllowOverride All and Options All expand attack surface. TRACE and long timeouts are unrelated to banners.

Question 32Host and middleware hardening foundations

On IIS, why should each site run in its own application pool with a dedicated low-privilege identity rather than LocalSystem?

  1. LocalSystem is required for Kernel-mode authentication and cannot be changed
  2. Dedicated identities prevent SQL injection in the application code
  3. Compromise of one worker process is contained; LocalSystem has machine-wide rights that turn a web bug into full host control Correct answer.
  4. Application pools disable HTTP.sys so TLS is no longer required

Explanation

IIS application-pool identities implement least privilege and isolation. LocalSystem (or overly powerful custom accounts) means a single RCE or file-write in the worker becomes a host compromise. Pools do not remove TLS. They also do not magically fix SQL injection; they limit OS impact after a bug.

Question 33Host and middleware hardening foundations

Tomcat Manager is reachable on the business interface with the installer default credentials. What is the correct specialist finding?

  1. Default credentials are acceptable if the port is 8080 instead of 80
  2. The finding is informational because Tomcat always requires a client certificate
  3. An exposed management console with default authentication is critical: it can deploy arbitrary WARs Correct answer.
  4. Manager is a read-only status page and cannot change the server

Explanation

Tomcat Manager/Host-Manager can deploy applications. Default or guessable credentials on a reachable interface are a direct path to code execution in the container. It is not read-only, port 8080 is not a control, and client certs are not on by default.

Question 34Host and middleware hardening foundations

Why is AllowOverride None a common Apache hardening recommendation on production document roots?

  1. It prevents .htaccess files from silently overriding authentication, options, and rewrite policy Correct answer.
  2. It disables TLS
  3. It is required for HTTP/2
  4. It enables directory listings

Explanation

When AllowOverride is not None, a writable .htaccess in the docroot can change Options, Auth, and rewrite rules - a persistence and bypass primitive after a file-write. None pushes config to the main server config under root control. It does not disable TLS or HTTP/2 and does not turn Indexes on.

Question 35Host and middleware hardening foundations

Apache mod_status is enabled and /server-status is reachable without access control from untrusted networks. What is disclosed?

  1. Live worker activity, request URIs, and other operational detail useful for reconnaissance Correct answer.
  2. Only the compile-time Apache version, which is already in the banner
  3. The contents of /etc/shadow
  4. WebLogic T3 handles

Explanation

mod_status shows vhost, request, and worker data. Unauthenticated exposure is sensitive operational recon (URLs, backends, load). It is more than the Server banner, it is not a shadow-file read, and it is not a WebLogic protocol.

Question 36Host and middleware hardening foundations

IIS WebDAV is enabled on a production site and unauthenticated or weakly authenticated clients can issue write methods. What is the risk?

  1. WebDAV automatically enables Credential Guard
  2. Write methods are ignored unless the site uses PHP
  3. Clients may upload or modify content on the site, which can become a web-shell or defacement path Correct answer.
  4. WebDAV only allows calendar sync and cannot write files

Explanation

WebDAV adds HTTP write verbs (PUT, PROPPATCH, MKCOL, and similar). On a web root, that is remote file write - a classic IIS compromise path. It is not limited to calendars, does not enable Credential Guard, and is independent of PHP.

Question 37Host and middleware hardening foundations

An IIS site still has 8.3 short-name generation enabled. Why do PTS testers treat tilde enumeration as more than a curiosity?

  1. 8.3 names disable Kerberos
  2. Tilde URLs bypass TLS
  3. Short names automatically grant Execute permission
  4. Short names can reveal otherwise hidden files and directories that a tester then requests by the guessed long name Correct answer.

Explanation

Windows 8.3 name generation lets testers infer secret filenames (backups, admin paths) that are not linked in HTML. That is information disclosure that often leads to extra attack surface. It does not disable Kerberos, bypass TLS, or grant execute rights by itself.

Question 38Host and middleware hardening foundations

Tomcat's AJP connector (historically port 8009) is bound to 0.0.0.0 on a host reachable from untrusted networks. Why is this a PTS-level middleware finding?

  1. AJP is just an alias for HTTPS and is safe on any interface
  2. AJP only serves static CSS
  3. Binding AJP to 0.0.0.0 enables SELinux automatically
  4. AJP is a trusted binary protocol between a front-end and Tomcat; exposing it has led to file-read/inclusion flaws (Ghostcat class) and bypasses of HTTP-layer controls Correct answer.

Explanation

AJP is meant for a private reverse-proxy backplane. When it is reachable, attackers speak AJP directly, which historically enabled Ghostcat (CVE-2020-1938) style file reads and can skip HTTP filters. It is not HTTPS, not CSS-only, and does not enable SELinux.

Question 39Host and middleware hardening foundations

Tomcat's DefaultServlet has readonly set to false on a public host. What capability does that add?

  1. Automatic HTTP/3
  2. Disabling the AJP connector
  3. Forcing every session cookie to HttpOnly
  4. HTTP PUT/DELETE against static content, i.e., remote file write/delete if no stronger auth exists Correct answer.

Explanation

DefaultServlet readonly=false is a documented way to allow PUT/DELETE on static resources. Combined with missing auth, it is a file-write finding. It does not enable HTTP/3, disable AJP, or set cookie flags.

Question 40Host and middleware hardening foundations

Oracle WebLogic Server exposes the T3/IIOP listener on the same internet-facing address as the HTTP application. What is the specialist concern?

  1. Public T3 automatically enables WebLogic production mode hardening
  2. T3/IIOP are Java RMI-style management/remote-object transports; they have a long history of deserialization and unauthenticated protocol issues and must not be public Correct answer.
  3. T3 is only a health-check ping and cannot deserialize objects
  4. IIOP is an IIS module that forces NTLM

Explanation

WebLogic T3 (and IIOP) carry Java remote invocations. PTS uniquely requires this middleware: internet exposure of T3/IIOP is a critical management-plane finding because of historically unauthenticated or weakly authenticated deserialization. T3 is not a ping. IIOP is CORBA/RMI-IIOP, not an IIS NTLM module. Production mode is a separate configuration.

Question 41Host and middleware hardening foundations

The WebLogic Administration Console is reachable on the production URL path without IP allowlisting or SSO. What should the report recommend first?

  1. Leave console public but change the GIF logo so attackers do not recognize it
  2. Disable HTTPS so the console cannot be cached
  3. Grant the console anonymous deploy rights to simplify operations
  4. Move administration to an isolated management network/port, require strong SSO/MFA, and block /console from untrusted networks Correct answer.

Explanation

WebLogic console can change configuration and deploy applications. PTS hardening is: do not put it on the business VIP, restrict source IPs, and use enterprise authentication. Cosmetic changes, disabling TLS, or anonymous deploy increase risk.

Question 42Host and middleware hardening foundations

A WebLogic component unmarshals XML with JDK XMLDecoder (or a similar XML-to-bean decoder) from an untrusted HTTP/T3 channel. How should a PTS code reviewer classify this?

  1. A harmless content-type mismatch
  2. Identical to missing X-Frame-Options
  3. Only a CSRF issue because the body is XML
  4. Insecure XML deserialization: XMLDecoder can instantiate arbitrary classes and invoke their setters from the document Correct answer.

Explanation

XMLDecoder is an object-graph decoder, not a data-only XML mapper. Untrusted XMLDecoder (historically abused on WebLogic WLS-WSAT style endpoints) is insecure deserialization. It is not clickjacking or CSRF. Report the decoder + trust boundary; do not attach a gadget recipe.

Question 43Host and middleware hardening foundations

IBM WebSphere Application Server's administrative console and SOAP connector share the same NIC as customer traffic. What is the correct architecture finding?

  1. Putting admin on the VIP enables HTTP/2 push
  2. The SOAP connector is a read-only Prometheus exporter
  3. Management endpoints (console, SOAP/JMX, IIOP) belong on a dedicated management interface and must not be reachable from the application VIP Correct answer.
  4. WebSphere requires the SOAP connector to be public for CDI to work

Explanation

WebSphere administration (ISC console, SOAP connector, RMI/IIOP) is a full control plane. PTS expects it to be network-isolated, authenticated, and not on the business address. CDI does not require a public SOAP admin port. The SOAP connector is not a metrics exporter.

Question 44Host and middleware hardening foundations

A legacy JBoss/WildFly instance still exposes the JMX console or JMX invoker without authentication on a reachable interface. Why is this treated as critical on PTS?

  1. Unauthenticated JMX invokers historically allowed remote invocation of MBeans, which is effectively remote code/config control Correct answer.
  2. JMX is a DNS protocol and only leaks hostnames
  3. JMX consoles cannot deploy or invoke, they only show HTML help
  4. JBoss JMX is only available over Unix sockets and cannot bind TCP

Explanation

Classic JBoss JMX console/invoker exposures are famous unauthenticated management-plane bugs. MBean invocation can deploy, execute, or reconfigure. JMX is Java Management Extensions over TCP/RMI, not DNS, and it is not help-only.

Question 45Host and middleware hardening foundations

A Java logging library interpolates attacker-controlled text into a JNDI lookup. Why did this class of issue become a specialist middleware/web finding?

  1. JNDI can resolve LDAP/RMI names into object factories, so an untrusted name becomes remote class loading or object reconstruction Correct answer.
  2. JNDI is only a local Properties file and cannot perform network lookups
  3. The issue is purely cosmetic banner leakage
  4. JNDI lookups require the attacker to have local SYSTEM rights first

Explanation

JNDI lookups of attacker-controlled names (the Log4Shell class of design) turn a string into a directory lookup that can return references and object factories. That is why message interpolation into JNDI is dangerous. JNDI is not local-only. It does not require prior SYSTEM. Report the lookup of untrusted names; do not include a working exploit string.

Question 46Host and middleware hardening foundations

A Windows IIS application pool is configured to run as LocalSystem. What is the primary privilege concern?

  1. LocalSystem strips HttpOnly from cookies
  2. A vulnerability in the web app or native module inherits LocalSystem, which is effectively full control of the host Correct answer.
  3. LocalSystem cannot access the network so the site will not serve clients
  4. LocalSystem automatically enables BitLocker

Explanation

LocalSystem is the most powerful local machine account. Running a network-facing worker as LocalSystem violates least privilege. It can access the network as the computer account. It does not enable BitLocker or change cookie flags.

Question 47Host and middleware hardening foundations

A Windows service account has SeImpersonatePrivilege. Why does PTS-level Windows review treat this as a privilege-escalation-relevant right?

  1. SeImpersonatePrivilege disables UAC permanently
  2. The right is required to read event logs and is therefore harmless
  3. It only applies to Linux capabilities
  4. Accounts that can impersonate client tokens may be able to coerce authentication and act as a more privileged user (token-impersonation class) Correct answer.

Explanation

SeImpersonatePrivilege is the core of many Windows service-to-SYSTEM impersonation techniques (the 'Potato' class conceptually). Testers should note service accounts that have it and whether the service is reachable. It does not disable UAC, is not required just to read logs, and is not a Linux capability.

Question 48Host and middleware hardening foundations

A Windows service ImagePath is unquoted and contains spaces (C:\Program Files\Vendor App\service.exe). Why is this a finding?

  1. Windows may try C:\Program.exe before the intended binary if that path is writable, yielding privilege escalation when the service runs as a privileged account Correct answer.
  2. Unquoted paths disable SMB signing
  3. Spaces in paths automatically drop SeDebugPrivilege
  4. The service cannot start unless the path is unquoted

Explanation

Unquoted service paths with spaces are a classic Windows misconfiguration: CreateProcess parsing can execute a different binary earlier in the path. If a low-privilege user can write that location, they escalate when the service starts. It is unrelated to SMB signing or SeDebugPrivilege.

Question 49Host and middleware hardening foundations

On Linux, a root-owned SUID binary is world-writable. What is the correct assessment?

  1. Critical: any local user can replace the binary and obtain root on execute Correct answer.
  2. Informational: SUID always ignores file mode bits
  3. Only a problem on systemd systems
  4. World-writable SUID is required for sudo to function

Explanation

SUID root plus a writable binary (or writable parent directory) is a direct local root path. SUID does not ignore write bits. Init system and sudo are unrelated.

Question 50Host and middleware hardening foundations

A Linux binary has cap_setuid+ep in getcap output. How should a tester interpret this relative to SUID?

  1. cap_setuid only affects containers' network namespaces
  2. getcap output is cosmetic and never enforced
  3. file capabilities can grant specific root-equivalent operations (here setuid) without the full SUID bit, so it is still a privilege boundary finding if the binary is unsafe Correct answer.
  4. capabilities always reduce privilege below a normal user

Explanation

Linux file capabilities split root powers. cap_setuid lets a process change UIDs - often as dangerous as SUID root if the program is buggy or writable. They are enforced by the kernel. They are not 'less than user' and not limited to netns.