Web / Software Security

Web application security

웹 애플리케이션 보안: XSS, SQL injection, GET login, password/session audit

웹 보안은 사용자의 문자열이 browser, SQL database, URL/log, session cookie 같은 문맥에서 데이터가 아니라 명령이나 비밀로 취급되는 순간을 줄 단위로 잡아내는 감사 훈련입니다.

초보자용 1타 강사식 설명

한 줄 핵심

웹 보안은 입력 문자열이 어느 해석기 앞에서 명령으로 바뀌는지 찾는 과목입니다.

쉽게 말하면

같은 글자라도 HTML 앞에서는 script가 되고, SQL 앞에서는 조건식이 되고, URL 안에서는 비밀 로그가 됩니다.

시험에서는

항상 vulnerable line -> attacker input -> context -> impact -> fix 순서로 쓰세요.

머릿속 그림: 초보자는 웹 서버를 한 덩어리로 보지만, 실제로는 여러 해석기(interpreter)가 줄지어 있습니다. 브라우저는 HTML과 JavaScript를 해석하고, 데이터베이스는 SQL을 해석하고, 서버와 프록시는 URL을 기록하고, 브라우저는 cookie를 자동으로 붙입니다. 같은 글자라도 어느 해석기 앞에 놓이느냐에 따라 안전한 데이터가 되기도 하고 공격 명령이 되기도 합니다.

$\text{web audit}=\text{vulnerable line}+\text{attacker input}+\text{context}+\text{impact}+\text{fix}$

Vulnerable line	Attacker input	Parser/context	Impact	Concrete fix
echo $_GET["q"] into HTML	<script>... or event-handler payload	Browser parses attacker data as HTML/JavaScript	XSS, session theft, actions as victim, phishing UI	Context-aware output encoding/templates; HttpOnly/SameSite as mitigation
"... WHERE user='$u' AND pass='$p'"	' OR 1=1 --	SQL parser changes WHERE clause semantics	Login bypass, data read/write, account takeover	Prepared statement with bound parameters and least privilege
<form method="GET"> for login	Normal credentials	URL/query string, logs, history, Referer	Password leaks outside the application boundary	POST over TLS; keep secrets out of URLs and logs
Plain or fast-hash password table	Database dump	Offline password guessing environment	Mass compromise and reuse attacks	Slow salted password hashing/KDF with cost parameter

Scored self-check

Web audit self-check

The web audit frame is vulnerable line -> attacker input -> context -> impact -> fix.

Vulnerable line is quoted or precisely identified. Attacker input is concrete, not just 'bad input'. Parser/context is named: HTML, JavaScript, SQL, URL/log, cookie, or DB storage. Impact is tied to a security goal. Fix is context-specific: output encoding, prepared statement, POST over TLS, KDF, or cookie flags.

0/5 slots checked. 먼저 답안에 들어간 채점 단위를 표시하세요.

핵심 용어 1타 설명

XSS

사용자 입력이 HTML/JavaScript로 실행되는 문제입니다. 답안은 output encoding을 바로 떠올리면 됩니다.

SQL injection

사용자 입력이 SQL 문법으로 섞여 query를 바꾸는 문제입니다. prepared statement가 핵심 방어입니다.

context

입력이 HTML 본문, attribute, JavaScript, SQL 중 어디에 들어가는지입니다. 방어도 context별로 달라집니다.

prepared statement

SQL 구조와 값을 분리해 SQLi를 막는 방식입니다. 문자열 escape보다 답안으로 강합니다.

output encoding

HTML에 출력할 때 특수문자를 데이터로 보이게 바꾸는 XSS 방어입니다.

session cookie

로그인 상태를 들고 다니는 토큰입니다. 탈취되면 계정처럼 쓰일 수 있어 HttpOnly/Secure/SameSite가 중요합니다.

오늘의 한 문장

웹 보안은 입력 문자열이 어느 해석기 앞에서 명령으로 바뀌는지 찾는 과목입니다.

왜 배우는가

같은 글자라도 HTML 앞에서는 script가 되고, SQL 앞에서는 조건식이 되고, URL 안에서는 비밀 로그가 됩니다.
항상 vulnerable line -> attacker input -> context -> impact -> fix 순서로 쓰세요.
시험에서는 용어 암기보다 상황을 답안 프레임으로 바꾸는 능력이 점수로 이어집니다.

머릿속 그림

초보자는 웹 서버를 한 덩어리로 보지만, 실제로는 여러 해석기(interpreter)가 줄지어 있습니다. 브라우저는 HTML과 JavaScript를 해석하고, 데이터베이스는 SQL을 해석하고, 서버와 프록시는 URL을 기록하고, 브라우저는 cookie를 자동으로 붙입니다. 같은 글자라도 어느 해석기 앞에 놓이느냐에 따라 안전한 데이터가 되기도 하고 공격 명령이 되기도 합니다.

단계별 강의

source와 sink를 찾습니다. source는 user input이고 sink는 HTML, SQL, URL, command 같은 해석기 앞입니다.
XSS는 HTML/JS context에서 input이 code처럼 실행되는 문제입니다.
SQL injection은 SQL query 문자열 구조가 attacker input으로 바뀌는 문제입니다.

시험 답안 프레임

XSS 답안은 vulnerable line, attacker payload, browser context, impact, context-aware output encoding을 씁니다.
SQLi 답안은 string concatenation, payload, WHERE clause 변화, login bypass/data leak, prepared statement를 씁니다.
GET login과 password storage는 각각 URL leakage와 DB dump/offline guessing 관점으로 설명합니다.

대표 함정

Prepared statement는 SQL injection 방어이지 XSS 방어가 아닙니다. HTML 출력은 context-aware output encoding이나 template auto-escaping으로 다룹니다.
POST는 비밀번호를 암호화하지 않습니다. POST는 URL 노출을 줄이고, 전송 중 보호는 TLS가 맡습니다.
Input validation 하나로 모든 web bug가 끝난다고 쓰면 감점입니다. interpreter별로 방어가 다릅니다.
Password hash만 쓰면 충분하다는 답은 약합니다. per-user salt, slow password hashing/KDF, cost parameter를 같이 써야 합니다.

미니 예제

`alice' OR 1=1 --`는 일반 문장으로 보면 이상하지만 SQL WHERE clause 안에서는 조건식을 바꾸는 명령 조각이 됩니다.

30초 구두시험

Web application security에서 공격자나 관찰자는 무엇을 할 수 있나요?
Web application security 답안에서 반드시 들어가야 하는 채점 단위는 무엇인가요?
Web application security의 대표 함정 하나와 반례를 말해 보세요.

우선 첨부할 소스

Vorlesung / 10 Web Application Security.pdf 29 windows
Vorlesung / 05 Authentifizierung.pdf 13 windows
Vorlesung / 09.pdf 9 windows
computersystemsicherheit_wise25-26_questions_only.md 8 windows
Übung / 06 / Übung6_sol.pdf 6 windows

구체 window 후보

CSS_Altklausur_WiSe_2526.pdf, windows/pages 1-2
CSS_Altklausur_WiSe_2526.pdf, windows/pages 5-6
CSS_Altklausur_WiSe_2526.pdf, windows/pages 11-12
CSS_Altklausur_WiSe_2526.pdf, windows/pages 13-14
CSS_Altklausur_WiSe_2526.pdf, windows/pages 15-16

AI 첨부 프롬프트

WS2025/26 Web Sicherheit memory protocol window/page 15, CSS_Exam_WiSe21_SoSe22_Altklausur Web- & Softwaresicherheit pages 15-16, Vorlesung 10 Web Application Security, Uebung 6 SQL injection material을 붙여서 XSS, SQL injection, GET login, password storage, session cookie, PHP audit을 vulnerable line -> attacker input -> context -> impact -> fix 형식으로 한국어로 아주 자세히 drill해 주세요.

복습 씨앗

참/거짓 연습

Web application security에서 '항상/절대/자동으로' 같은 표현이 나오면 반례를 먼저 찾아보세요.
방어 기법 하나가 모든 공격을 막는다고 하면 대체로 함정입니다.

구두 연습

Web application security에서 공격자나 관찰자는 무엇을 할 수 있나요?
Web application security 답안에서 반드시 들어가야 하는 채점 단위는 무엇인가요?
Web application security의 대표 함정 하나와 반례를 말해 보세요.

한국어로 답하세요. 중요한 용어만 English/German 병기: topic=Web application security, answer frame, attacker capability, defense limit, common trap

취약 주제 키

web-application-security high exam signal

Software security

소프트웨어 보안: C buffer overflow, sprintf, system(), command injection, fuzzing

소프트웨어 보안은 입력 길이, 메모리 경계, shell 명령 실행 같은 낮은 수준의 약속을 코드가 깨는 줄을 찾아 공격 입력과 수리 방법까지 설명하는 코드 감사입니다.

초보자용 1타 강사식 설명

한 줄 핵심

소프트웨어 보안은 위험한 sink로 들어가는 attacker-controlled input을 찾는 훈련입니다.

쉽게 말하면

C buffer는 자동으로 크기를 지켜주지 않고, shell은 문자열을 명령문으로 다시 해석합니다.

시험에서는

sprintf/strcpy/system 문제는 line, input, memory/shell context, impact, repair를 따로 쓰면 됩니다.

머릿속 그림: C 프로그램을 칸이 정해진 작업대라고 생각하면 됩니다. `char buf[16]`은 16칸뿐인데, 길이를 재지 않고 100칸짜리 문자열을 밀어 넣으면 옆 칸의 값, 저장된 frame pointer, return address 같은 것이 망가질 수 있습니다. `system()`은 사용자가 쓴 문장을 shell이라는 두 번째 해석기에게 그대로 읽어 주는 확성기입니다.

$\text{software audit}=\text{vulnerable line}+\text{attacker input}+\text{memory/shell context}+\text{impact}+\text{fix}$

Vulnerable line	Attacker input	Memory/shell context	Impact	Repair
sprintf(buf, "%s", user)	String longer than buf	C stack/heap buffer without length bound	Crash, memory corruption, possible control-flow hijack	snprintf with size, bounds checks, safer APIs, compiler hardening
strcpy(dst, argv[1])	Oversized command-line argument	Unbounded copy into fixed buffer	Overwrite adjacent memory or return metadata	Length validation and bounded copy; prefer safer design
system("ping " + host)	example.com; whoami	Shell interprets metacharacters	Command injection under application privileges	Allowlist host syntax; call non-shell API with argument vector
Unchecked parser length field	Malformed file/network packet	Parser trusts attacker-controlled size	Out-of-bounds read/write or denial of service	Validate length before allocation/copy and fuzz boundary cases

Scored self-check

Software audit self-check

Code answers score better when they name the exact sink and the exact replacement pattern.

Vulnerable line is identified. Attacker-controlled source and input shape are stated. Memory/shell/parser context is named. Impact is not overclaimed: crash, corruption, command execution, or DoS. Repair is API-level: snprintf, bounds check, no shell, argument vector, allowlist, fuzz regression.

0/5 slots checked. 먼저 답안에 들어간 채점 단위를 표시하세요.

핵심 용어 1타 설명

buffer overflow

정해진 메모리 칸보다 많은 데이터를 써서 옆 영역을 덮는 버그입니다.

sprintf

출력 길이를 제한하지 않으면 buffer overflow로 이어질 수 있는 C 함수입니다.

system()

문자열을 shell 명령으로 실행합니다. 사용자 입력이 들어가면 command injection을 의심해야 합니다.

command injection

입력에 `;`, `&&`, `|` 같은 shell 문법을 넣어 원래 의도와 다른 명령을 실행시키는 공격입니다.

fuzzing

많은 입력을 자동으로 던져 crash나 memory error를 찾는 테스트 방법입니다.

repair

시험에서는 '안전하게 고친다'가 아니라 snprintf, length check, allowlist, shell 제거처럼 구체적으로 써야 합니다.

오늘의 한 문장

소프트웨어 보안은 위험한 sink로 들어가는 attacker-controlled input을 찾는 훈련입니다.

왜 배우는가

C buffer는 자동으로 크기를 지켜주지 않고, shell은 문자열을 명령문으로 다시 해석합니다.
sprintf/strcpy/system 문제는 line, input, memory/shell context, impact, repair를 따로 쓰면 됩니다.
시험에서는 용어 암기보다 상황을 답안 프레임으로 바꾸는 능력이 점수로 이어집니다.

머릿속 그림

C 프로그램을 칸이 정해진 작업대라고 생각하면 됩니다. `char buf[16]`은 16칸뿐인데, 길이를 재지 않고 100칸짜리 문자열을 밀어 넣으면 옆 칸의 값, 저장된 frame pointer, return address 같은 것이 망가질 수 있습니다. `system()`은 사용자가 쓴 문장을 shell이라는 두 번째 해석기에게 그대로 읽어 주는 확성기입니다.

단계별 강의

C 코드에서는 입력 길이와 destination buffer 크기를 비교합니다.
`sprintf`, `strcpy`, `gets`처럼 길이 제한이 약한 sink는 overflow 후보입니다.
`system()`은 문자열을 shell parser에게 다시 넘기므로 command injection 후보입니다.

시험 답안 프레임

Buffer overflow 답안은 line, oversized input, memory overwrite context, crash/control-flow impact, bounds check/snprintf fix를 씁니다.
Command injection 답안은 metacharacter, intended command, injected command, shell context, avoid-shell API fix를 씁니다.
Fuzzing은 bug discovery 기법이지 안전성 증명이 아니라고 한계를 붙입니다.

대표 함정

Buffer overflow를 항상 remote code execution이라고 단정하면 안 됩니다. crash, memory corruption, information leak, control-flow hijack 가능성처럼 범위를 정확히 말합니다.
`snprintf`로 바꾸면 끝이라고 쓰면 약합니다. return value, truncation, null termination, semantic correctness도 확인해야 합니다.
`system()` 앞에서 escaping을 잘하면 된다는 답보다 shell을 피하고 argument-vector API를 쓰는 답이 더 강합니다.
Fuzzing에서 crash가 안 나왔다고 secure proof가 생기는 것은 아닙니다. 입력공간을 샘플링해 confidence를 높이는 기법입니다.

미니 예제

`system('ping ' + host)`에서 host가 `example.com; whoami`이면 shell은 ping 뒤에 whoami도 실행할 수 있습니다.

30초 구두시험

Software security에서 공격자나 관찰자는 무엇을 할 수 있나요?
Software security 답안에서 반드시 들어가야 하는 채점 단위는 무엇인가요?
Software security의 대표 함정 하나와 반례를 말해 보세요.

우선 첨부할 소스

Vorlesung / 11_software-security 10.pdf 27 windows
Vorlesung / Vorlesung IT-Forensik 2026.pdf 11 windows
Vorlesung / 10 Web Application Security.pdf 7 windows
Vorlesung / 01_Einfuehrung_RMU 2.pdf 5 windows
Vorlesung / 03 Symmetrische Kryptographie.pdf 4 windows

구체 window 후보

CSS_Altklausur_WiSe_2526.pdf, windows/pages 1-2
CSS_Altklausur_WiSe_2526.pdf, windows/pages 15-16
CSS_Altklausur_WiSe_2526.pdf, windows/pages 17-18
computersystemsicherheit_wise25-26_questions_only.md, window/page 18
computersystemsicherheit_wise25-26_questions_only.md, window/page 19

AI 첨부 프롬프트

WS2025/26 memory protocol Software Security note, CSS_Exam_WiSe21_SoSe22_Altklausur Buffer Overflow pages 15-17, Vorlesung 11 software-security, relevant exercise snippets를 붙여서 C buffer overflow, sprintf, system(), command injection, fuzzing을 vulnerable line -> attacker input -> context -> impact -> fix 형식으로 한국어로 아주 자세히 drill해 주세요.

복습 씨앗

참/거짓 연습

Software security에서 '항상/절대/자동으로' 같은 표현이 나오면 반례를 먼저 찾아보세요.
방어 기법 하나가 모든 공격을 막는다고 하면 대체로 함정입니다.

구두 연습

Software security에서 공격자나 관찰자는 무엇을 할 수 있나요?
Software security 답안에서 반드시 들어가야 하는 채점 단위는 무엇인가요?
Software security의 대표 함정 하나와 반례를 말해 보세요.

한국어로 답하세요. 중요한 용어만 English/German 병기: topic=Software security, answer frame, attacker capability, defense limit, common trap

취약 주제 키

software-security high exam signal

이 페이지에서 보는 것

웹 애플리케이션 보안: XSS, SQL injection, GET login, password/session audit

Web/code audit highlighter

Web audit self-check

핵심 용어 1타 설명

오늘의 한 문장

왜 배우는가

머릿속 그림

단계별 강의

시험 답안 프레임

대표 함정

미니 예제

30초 구두시험

우선 첨부할 소스

AI 첨부 프롬프트

복습 씨앗

참/거짓 연습

구두 연습

취약 주제 키

소프트웨어 보안: C buffer overflow, sprintf, system(), command injection, fuzzing

Software audit highlighter

Software audit self-check

핵심 용어 1타 설명

오늘의 한 문장

왜 배우는가

머릿속 그림

단계별 강의

시험 답안 프레임

대표 함정

미니 예제

30초 구두시험

우선 첨부할 소스

AI 첨부 프롬프트

복습 씨앗

참/거짓 연습

구두 연습

취약 주제 키