AP21 — Major Attack Techniques and Layered Defenses

Separate SQL injection, XSS and CSRF by root cause, layer defenses for phishing, ransomware and DDoS, and compare firewall, WAF, IDS and IPS for AP Subject A, with five original questions.

応用情報技術者試験科目A情報セキュリティ攻撃手法多層防御

AP Subject A · Installment 21 · An independent study resource for the 2026 exam and Syllabus Ver.7.2. It is not affiliated with IPA and does not guarantee a pass. Open the series hub

Original study material · basis: AP Subject A (2026), IPA Syllabus Ver.7.2 · revised/sources checked: 2026-10-21

Revision history: 2026-10-28 corrected the incident-management lifecycle reference from AP22 to AP25.

Learning index

After this lesson, you should be able to:

  1. Separate SQL injection, XSS, and CSRF by root cause → impact → primary defense → limits of secondary controls.
  2. Select prevention, detection, response, and recovery layers for phishing, ransomware, and DoS/DDoS.
  3. Explain what firewalls, WAFs, IDSs, and IPSs observe and do.
  4. Choose the most direct control in a short exam case.

Exact IPA Ver.7.2 mapping

The first number below is the PDF page; the second is the printed footer page.

PDF/footer Major category → middle category → item Connection to this lesson
53/49 Major Category 3 Technical Elements → Middle Category 11 Security → 1. Information Security → (3) Threats → ② Malware and malicious programs Ransomware
54/50 Same hierarchy → 1. Information Security → (7) Attack methods XSS, CSRF, SQL injection, phishing, DoS/DDoS, targeted attacks, and related classes
57/53 Major Category 3 Technical Elements → Middle Category 11 Security → 2. Information Security Management → (6) Incident management Detection/reception, triage, response, reporting/disclosure
59/55 Major Category 3 Technical Elements → Middle Category 11 Security → 4. Information Security Countermeasures → (1) Types → ② Technical measures 3-2-1/WORM/immutable backups, privileges, logs, patches, monitoring, FW/WAF/IDS/IPS/EDR/SIEM
60/56 Same middle category → 5. Security Implementation Technology → (4) Network security, (5) Database security, and start of (6) Application security Filtering, reverse proxies, DB access/backup/logging, secure programming, vulnerability testing
61/57 Same hierarchy → 5. Security Implementation Technology → continuation of (6) Application security XSS controls and SQL-injection controls including placeholders

AP19 cryptography/certificates and AP20 authentication/access-control foundations are only cross-references here. Least privilege appears only as one damage-limiting layer. The full incident lifecycle belongs to AP25; this lesson uses only the compact detect → respond → recover link.

Shared terminology table

English 한국어 日本語
SQL injection SQL 인젝션 SQLインジェクション
Cross-site scripting (XSS) 크로스 사이트 스크립팅(XSS) クロスサイトスクリプティング(XSS)
Cross-site request forgery (CSRF) 크로스 사이트 요청 위조(CSRF) クロスサイトリクエストフォージェリ(CSRF)
Phishing 피싱 フィッシング
Ransomware 랜섬웨어 ランサムウェア
Denial of service (DoS/DDoS) 서비스 거부 공격(DoS/DDoS) サービス妨害攻撃(DoS/DDoS)
Firewall 방화벽 ファイアウォール
Web application firewall (WAF) 웹 애플리케이션 방화벽(WAF) Webアプリケーションファイアウォール(WAF)
Intrusion detection system (IDS) 침입 탐지 시스템(IDS) 侵入検知システム(IDS)
Intrusion prevention system (IPS) 침입 방지 시스템(IPS) 侵入防止システム(IPS)
Defense in depth 심층 방어 多層防御
Immutable backup 불변 백업 イミュータブルバックアップ

1. Distinguish three web attacks by cause

SQL injection

  • Root cause: untrusted data is composed into the structure of an SQL command.
  • Impact: unintended reads, changes, deletion, authentication bypass, or disclosure may result.
  • Primary design defense: bind values through parameterized queries/prepared statements/placeholders, separating code from data. For dynamic identifiers that cannot be bound—such as a table name or sort direction—select only server-defined allow-listed choices. Give the database account least privilege.
  • Secondary-control limits: validation, logging, and a WAF may help detect or mitigate attacks, but they do not repair unsafe query construction. Manual escaping is context- and configuration-sensitive and is not the primary fix.

XSS

  • Root cause: untrusted data is interpreted as executable browser content in an HTML/script context.
  • Impact: page modification, unintended actions in the user’s session, or exposure of sensitive data may follow.
  • Primary design defense: use context-sensitive output encoding for the exact destination (HTML body, attribute, URL, JavaScript, and so on), plus safe sinks such as text-only DOM APIs or auto-escaping templates. Validate inputs that have a well-defined allowed form.
  • Secondary-control limits: CSP and WAF are defense-in-depth, not substitutes for safe output handling. Encoding for one context must not be reused blindly in another.

CSRF

  • Root cause: a browser holding an authenticated session is induced to send an unwanted state-changing request with valid credentials.
  • Impact: an unintended settings change, transfer, registration, or deletion may occur.
  • Primary design defense: use the framework’s CSRF protection or unpredictable anti-CSRF tokens validated by the server. Add appropriate SameSite cookies and Origin/Referer checks as layers. Do not use GET for state changes.
  • Secondary-control limits: XSS output encoding is not the primary CSRF fix, and CORS alone is insufficient. XSS can also defeat some CSRF defenses, so both flaws must be fixed.

Memory cue: SQLi protects server query structure; XSS protects browser output context; CSRF validates the intent of an authenticated browser request.

2. Attacks on people, endpoints, and services

Phishing

Synthetic case: an employee receives “our supplier changed its bank account.” Instead of following the link or paying, the employee verifies through a separately stored official contact. The organization layers user verification/training and reporting, mail/web filtering, least privilege, endpoint monitoring, protected centralized logs, and incident handling. Training is not assumed to stop every deception.

Ransomware

Synthetic case: an endpoint raises an alert for unusual mass file changes. Following the approved procedure, the team isolates it, determines scope using protected centralized logs, and restores tested offline/immutable backups into an environment confirmed clean.

  • Patching reduces known-vulnerability paths, but not phishing, misconfiguration, unknown flaws, or every other path.
  • Least privilege and segmentation limit movement and blast radius.
  • The 3-2-1 rule, WORM or immutable storage, and restoration tests improve recoverability. Backups do not prevent infection or data theft. Always-online backups may be damaged too.
  • Logs help detection and investigation only when collected, protected from alteration, and reviewed. A log does not itself block an attack.

DoS/DDoS

Synthetic case: traffic from distributed sources overwhelms a public service and delays legitimate users. A server-local firewall cannot by itself undo an already saturated upstream link. Combine provider-coordinated upstream DDoS mitigation, CDN/anycast distribution, appropriate rate limiting, cache/capacity design, monitoring, and a response procedure. Rate limits can reject legitimate surges, and capacity alone cannot absorb every attack, so baselines and tests matter.

3. Firewall, WAF, IDS, and IPS

Control Main observation/action Strength Limit/caution
Firewall Network/transport connection policy using state, addresses, and ports Reduces unnecessary connection paths Cannot repair application code and may miss harmful semantics in allowed traffic
WAF Inspects and blocks HTTP/application requests Compensating layer for web requests Has false positives/negatives; never substitutes for secure coding
IDS Detects and alerts after observing traffic/events Adds visibility and investigation clues Generally does not block automatically; alerts require review
IPS Detects and blocks inline Can immediately reject known/policy-violating traffic Requires tuning; false positives and performance/availability effects are possible

No product is universal. Encryption, allowed flows, and sensor placement determine visibility. Layer secure design, patching, privileges, segmentation, monitoring, and recovery.

4. Safe worked decisions

Example A — web request/data flow

A search API accepts a search term and sort choice, queries a database, then renders results into HTML.

  1. Bind the search value to a prepared-statement placeholder.
  2. Choose the sort column and direction only from a server-defined allow-list.
  3. Encode each result for its output context and use a safe template/sink.
  4. Give the database account only the required read permissions.
  5. Add a WAF and protected logs as extra detection/mitigation layers.

This removes the primary SQLi and XSS causes in code, then limits residual risk with least privilege and a WAF.

Example B — incident defense and recovery

An employee reports a suspicious attachment, followed by an endpoint alert for unusual changes.

  1. Receive and triage the report/alert; isolate the affected endpoint under the approved procedure.
  2. Use protected centralized logs to investigate the account, endpoint, time window, and scope.
  3. Address exposed credentials and the entry path; confirm how segmentation and least privilege constrained spread.
  4. After confirming a clean environment, restore from a tested offline/immutable backup and verify normal operation.
  5. Hand required reporting and improvements to the organization’s process.

Restoring immediately over the system can leave the cause intact and destroy evidence. AP25 covers the full incident lifecycle.

5. Original four-choice questions

All cases below are safe conceptual questions created for this lesson; none is an IPA past question.

Question 1

A web application builds SQL by concatenating strings. What is the most direct primary control?

  • ア. Install only an IDS in front of the database server.
  • イ. Bind values using prepared-statement placeholders and allow-list dynamic identifiers.
  • ウ. Hide only error messages.
  • エ. Have developers manually escape every input.

Answer: イ (2)

  • ア: It may provide detection evidence but does not fix query construction.
  • イ: It directly separates code from data and addresses the root cause.
  • ウ: It can reduce disclosure while leaving injection possible.
  • エ: It is context/configuration-sensitive and unreliable as the primary defense.

Question 2

After a logged-in user opens an attacker-controlled page, an unwanted address-change request is sent. Which explanation and control fit best?

  • ア. It is XSS, so use only HTML output encoding.
  • イ. It is SQL injection, so reduce only DB privilege.
  • ウ. CORS configuration alone solves every case.
  • エ. It is CSRF; use a validated anti-CSRF token with appropriate SameSite/Origin checks.

Answer: エ (4)

  • ア: The core event is an unwanted authenticated request, not executable output.
  • イ: No SQL structure was changed.
  • ウ: CORS alone is not the primary CSRF defense.
  • エ: It combines a cause-specific primary defense and supporting layers.

Question 3

An employee receives a bank-account-change message while an endpoint reports suspicious file changes. What is the best combination?

  • ア. Verify through a separate official contact and report it; then isolate/investigate under procedure and restore a tested offline/immutable backup into a clean environment.
  • イ. Skip endpoint investigation because a backup exists.
  • ウ. Assume phishing is impossible when patches are current.
  • エ. Preserve no logs and immediately reset every system.

Answer: ア (1)

  • ア: It layers human verification, detection, response, and recovery.
  • イ: Backup does not stop infection/theft, and the cause may remain.
  • ウ: Patches do not cover every attack path.
  • エ: This loses scope/evidence and may cause excessive disruption.

Question 4

High-volume traffic from distributed sources saturates an Internet link. What is the best preparation?

  • ア. Increase only the internal IDS alert count.
  • イ. Strengthen only application output encoding.
  • ウ. Combine upstream DDoS mitigation, CDN/anycast, appropriate rate limiting/capacity, and monitoring.
  • エ. Reduce only the database account’s privileges.

Answer: ウ (3)

  • ア: Detection alone cannot recover an upstream link that is saturated.
  • イ: This is an XSS control, not the direct availability control.
  • ウ: It layers controls before and after traffic reaches the service.
  • エ: It may limit some damage but cannot resolve link saturation.

Question 5

Which statement about firewalls, WAFs, IDSs, and IPSs is most accurate?

  • ア. A firewall always understands all harmful semantics inside allowed HTTP.
  • イ. An IDS mainly detects/alerts, an IPS can block inline, and a WAF is an HTTP compensating control; all require tuning and layering.
  • ウ. A WAF removes the need to repair vulnerable application code.
  • エ. An IPS cannot create false positives or availability effects.

Answer: イ (2)

  • ア: Policy, encryption, and placement limit firewall visibility.
  • イ: This accurately describes both roles and limits.
  • ウ: A WAF is not a substitute for secure coding.
  • エ: Bad inline tuning can affect legitimate traffic and performance.

Answer key: 1–5 = [2, 4, 1, 3, 2] = [イ, エ, ア, ウ, イ]

Quick sheet

  • SQLi: separate query structure → parameters/placeholders; allow-list dynamic identifiers.
  • XSS: separate browser context → contextual output encoding and safe sinks.
  • CSRF: validate request intent → framework protection/token plus SameSite/Origin layers.
  • Backups recover; least privilege/segmentation limit blast radius; logs detect/investigate.
  • Firewall = connection policy; WAF = HTTP inspection; IDS = alert; IPS = inline block.
  • No single control is universal: layer prevention, detection, response, and recovery.

Self-check

  • I can state what SQLi, XSS, and CSRF each protect in one sentence.
  • I can explain what backups, patches, least privilege, and logs do not do.
  • I can compare firewall/WAF/IDS/IPS and their false-positive/visibility limits.
  • I can reconstruct both worked decisions without looking.
  • I can explain why every distractor in the five questions is wrong.

Official sources

Checked 2026-10-21: IPA Syllabus Ver.7.2; OWASP prevention guidance for SQL injection, XSS, and CSRF; CISA StopRansomware and DDoS guidance; NIST SP 800-61 Rev.3, SP 800-41 Rev.1, and SP 800-94.

1/3/7-day review

  • After 1 day: hide the quick sheet and write the cause and primary defense for each web attack.
  • After 3 days: rebuild both cases and add one limitation beside every chosen control.
  • After 7 days: retake all five questions and rewrite each wrong option as a correct statement.

This material claims no affiliation with or endorsement by IPA and makes no exam-success guarantee.

Back to the blog