좋은 커밋 메시지는 한눈에 변경 내용의 의도와 범위를 파악할 수 있어야 한다. 기본 구조는 제목(Subject), 본문(Body), 바닥글(Footer)의 3단계 구성을 따른다. 각 영역은 빈 줄(New Line)로 구분한다.

type(scope): 제목 (Subject)

본문 (Body) - 생략 가능

바닥글 (Footer) - 생략 가능

• 제목: 변경의 종류(type)와 핵심 내용을 한 줄로 요약한다.
• 본문: "무엇을", "왜" 변경했는지 상세히 서술한다. (선택 사항)
• 바닥글: 이슈 트래커 ID(예: Jira, GitHub Issues)나 Breaking Change(중대 변경)를 명시한다. (선택 사항)

🛠️ 1. 제목 (Subject) 작성 규칙

제목은 컨벤션의 핵심이다. 현업에서 가장 많이 쓰이는 7가지 대표 Type을 숙지하고 일관되게 사용한다.

7가지 핵심 커밋 타입 (Type)

💡 Scope(범위) 활용하기 (선택) 변경 사항이 특정 모듈이나 도메인에 국한된다면 괄호를 이용해 범위를 명시한다. 한눈에 파악하기 매우 용이해진다.

• 예: feat(order): 주문 추가 시 중복 제약 조건 로직 구현
• 예: chore(deps): lodash 라이브러리 버전 업데이트

제목 작성 5대 원칙

1. 타입 뒤에는 콜론과 공백을 둔다: feat: 내용 (O) / feat:내용 (X)
2. 첫 글자는 대문자로 시작하지 않는다: 영문 작성 시 소문자로 시작하는 것이 관례다. (타입과의 통일성)
3. 명령문 형태로 작성한다: "했음" 보다는 "함", "추가", "수정" 형태로 간결하게 작성한다.
4. 끝에 마침표(.)를 찍지 않는다.
5. 글자 수는 50자 내외로 제한한다.

📝 2. 본문 (Body) 작성 규칙 (선택 사항)

변경의 맥락이 복잡하여 제목 한 줄로 서술이 불가능할 때 작성한다. 단순 버그 수정이나 자잘한 수정 시에는 과감히 생략한다.

• 부연 설명이 필요할 때 사용하며, 최대 72자마다 줄바꿈을 한다.
• "어떻게 변경했는지"보다 "무엇을", "왜" 변경했는지에 집중하여 작성한다.

fix(auth): JWT 토큰 만료 시 간헐적 튕김 현상 수정

- 기존 익스파이어 타임 계산 로직의 시차 밀리초 계산 오류 확인
- 서버 타임존 기준과 브라우저 타임존을 UTC로 통일하여 오차 범위를 제거함

⚓ 3. 바닥글 (Footer) 작성 규칙 (선택 사항)

주로 협업 도구와의 연동이나 프로젝트의 중대한 변화를 알릴 때 사용한다.

Issue Tracker 연동 (GitHub, Jira 등)

이슈 번호를 명시하여 해당 커밋이 어떤 태스크와 연결되어 있는지 추적할 수 있게 한다. GitHub의 경우 특정 키워드와 함께 사용하면 푸시 시 이슈가 자동으로 닫힌다.

• 키워드: Fixes, Closes, Resolves
• 예시: 규약 키워드: #이슈번호 ➡️ Closes: #124

BREAKING CHANGE (중대 변경 사항)

이전 버전과의 하위 호환성이 깨지는 대대적인 API 변경이나 구조적 변경이 있을 때 바닥글 맨 앞에 BREAKING CHANGE:를 붙여 동료 개발자들에게 강력한 경고를 전달한다.

feat(api): V2 주문 인터페이스 스펙 변경

BREAKING CHANGE: 기존 /api/v1/order API가 폐기됨. 
이제 모든 클라이언트는 /api/v2/order 헤더 기반 인증 방식을 사용해야 함.

Ref: #204
Closes: #205

💡 현업 실용 팁: 한 눈에 보는 올바른 예시

올바른 예시 🟢

feat(cart): 장바구니 상품 수량 변경 API 연동

- 수량 변경 시 즉각적으로 총 금액이 리프레시되도록 훅 연결
- 최소 수량 1개 미만으로 내려갈 시 하단 경고 토스트 팝업 추가

Closes: #42

fix: 데이터베이스 연결 타임아웃 예외 처리 예외 구간 확장

style: 코드 포맷팅 및 사용하지 않는 임포트 구문 제거

잘못된 예시 🔴

Fix: 로그인 고쳤음. (타입 뒤 공백 없음, 마침표 사용, 과거형 서술)

수정 (영어 타입 미사용, 일관성 결여)

feat: 어제 짜다 만 장바구니 기능 마저 구현하고 중간 저장함 (지나치게 감정적이거나 사적인 서술)

🥊 요약

컨벤션은 절대적인 정답이 아니라 팀원 간의 약속이다. 위의 Conventional Commits 스타일을 기본 뼈대로 삼고, 팀의 성격에 맞게 조금씩 변형하여 활용한다면 누구나 읽기 편한 깔끔한 히스토리를 유지할 수 있다. 처음에는 어색할지라도 type을 먼저 정의하고 커밋하는 습관을 들이면 코드의 분리(Atomic Commit)도 자연스럽게 이루어지게 된다.

SSRF Lab https://portswigger.net/web-security/all-labs#server-side-request-forgery-ssrf

Circumventing common SSRF defenses

SSRF with blacklist-based input filters

Some applications block input containing hostnames like 127.0.0.1 and localhost, or sensitive URLs like /admin. In this situation, you can often circumvent the filter using the following techniques:

Use an alternative IP representation of 127.0.0.1, such as 2130706433, 017700000001, or 127.1.

→ 다음과 같은 우회 방식을 시도해볼 수 있다.

• 10진수(Decimal): 2130706433 (127.0.0.1을 10진수 정수로 변환한 값)
• 8진수(Octal): 017700000001 (각 마디를 8진수로 변환)
• 16진수(Hexadecimal): 0x7f000001
• 생략: 127.1 (중간의 0을 생략해도 운영체제는 127.0.0.1로 해석)

Register your own domain name that resolves to 127.0.0.1. You can use spoofed.burpcollaborator.net for this purpose.

→ 127.0.0.1이라는 숫자 대신, 이 IP를 가리키는 도메인 이름을 사용

• 원리: 서버 필터는 URL에 "127"이나 "localhost"가 있는지 검사한다. 하지만 공격자가 my-loopback.com이라는 도메인을 사고, 이 도메인의 DNS A 레코드를 127.0.0.1로 설정하면 필터는 일반적인 외부 도메인으로 인식하여 통과시킨다.
• 활용: Burp Suite의 spoofed.burpcollaborator.net처럼 이미 127.0.0.1로 연결되도록 설정된 공개 도메인을 사용할 수도 있다.

Obfuscate blocked strings using URL encoding or case variation.

→ 난독화 (Obfuscation): 필터가 차단하는 특정 단어(예: /admin)를 알아보기 힘들게 비트는 방법

• URL 인코딩: /admin 대신 %61%64%6d%69%6e으로 전달한다. 서버 내부에서 이를 다시 디코딩하여 처리할 경우 필터를 우회하게 된다.
• 대소문자 변환: 필터가 대소문자를 구분한다면 /ADMIN 또는 /aDmIn으로 시도하여 차단을 피할 수 있다.

Provide a URL that you control, which redirects to the target URL. Try using different redirect codes, as well as different protocols for the target URL. For example, switching from an http: to https: URL during the redirect has been shown to bypass some anti-SSRF filters.

→ 리다이렉트 활용 (HTTP Redirect): 서버가 입력받은 URL을 검사할 때와 실제로 접속할 때의 차이를 이용

• 공격자가 제어하는 외부 서버(http://attacker.com/move)를 입력한다.
• 서버의 필터는 "외부 주소이므로 안전하다"고 판단하고 요청을 허용한다.
• 공격자의 서버는 이 요청을 받을 때 302 Redirect 응답과 함께 Location: http://127.0.0.1/admin 헤더를 보낸다.
• 대상 서버는 리다이렉트 지시에 따라 내부의 127.0.0.1/admin으로 다시 접속하게 된다.
• 이 과정에서 프로토콜을 http:에서 https:로 바꾸거나 그 반대로 바꾸는 방식이 필터의 로직을 꼬이게 만들어 우회에 성공하기도 한다.

#3 Lab: SSRF with blacklist-based input filter

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.

The developer has deployed two weak anti-SSRF defenses that you will need to bypass.

사용 툴: Burp Suite

http://127.1/ 또는 http://2130706433/ 우회 시도 차단

URL 인코딩 http://127.1/%61%64%6d%69%6e 차단

이중 URL 인코딩 http://127.1/%2561%2564%256d%2569%256e 우회 시도 성공

http://127.1/%2561%2564%256d%2569%256e/delete?username=carlos로 삭제 성공

LAB Solved!

SSRF with whitelist-based input filters

Some applications only allow inputs that match, a whitelist of permitted values. The filter may look for a match at the beginning of the input, or contained within in it. You may be able to bypass this filter by exploiting inconsistencies in URL parsing.

The URL specification contains a number of features that are likely to be overlooked when URLs implement ad-hoc parsing and validation using this method:

You can embed credentials in a URL before the hostname, using the @ character. For example: https://expected-host:fakepassword@evil-host

You can use the # character to indicate a URL fragment. For example: https://evil-host#expected-host

You can leverage the DNS naming hierarchy to place required input into a fully-qualified DNS name that you control. For example: https://expected-host.evil-host

You can URL-encode characters to confuse the URL-parsing code. This is particularly useful if the code that implements the filter handles URL-encoded characters differently than the code that performs the back-end HTTP request. You can also try double-encoding characters; some servers recursively URL-decode the input they receive, which can lead to further discrepancies. You can use combinations of these techniques together.

#4 Lab: SSRF with whitelist-based input filter

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.

The developer has deployed an anti-SSRF defense you will need to bypass.

view details

Check stock repeater로 보냄

stockApi=http://127.0.0.1/로 변경하여 send 요청 차단됨. host는 stock.weliketoshop.net이어야만 함을 확인

stockApi=http://username:password@stock.weliketoshop.net/로 바꾸어 전송 시 500 응답을 받는 것 확인

stockApi=http://localhost:80%2523@stock.weliketoshop.net/

• http://localhost:80: 도달하고자 하는 진짜 목적지

• @: URL에서 호스트명 앞에 사용자 이름이나 비밀번호를 넣을 때 사용하는 구분자

• # (%2523): 페이지 내부 위치를 나타내는 프래그먼트 구분자. 시스템은 # 이후의 문자열을 무시

• stock.weliketoshop.net: 서버가 허용한 Whitelist 목적지

stockApi=http://localhost:80%2523@stock.weliketoshop.net/admin/delete?username=carlos

LAB Solved!

Bypassing SSRF filters via open redirection

Bypassing SSRF filters via open redirection It is sometimes possible to bypass filter-based defenses by exploiting an open redirection vulnerability.

In the previous example, imagine the user-submitted URL is strictly validated to prevent malicious exploitation of the SSRF behavior. However, the application whose URLs are allowed contains an open redirection vulnerability. Provided the API used to make the back-end HTTP request supports redirections, you can construct a URL that satisfies the filter and results in a redirected request to the desired back-end target.

For example, the application contains an open redirection vulnerability in which the following URL:

/product/nextProduct?currentProductId=6&path=http://evil-user.net

returns a redirection to:

http://evil-user.net

You can leverage the open redirection vulnerability to bypass the URL filter, and exploit the SSRF vulnerability as follows:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin

This SSRF exploit works because the application first validates that the supplied stockAPI URL is on an allowed domain, which it is. The application then requests the supplied URL, which triggers the open redirection. It follows the redirection, and makes a request to the internal URL of the attacker's choosing.

#5 Lab: SSRF with filter bypass via open redirection vulnerability

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://192.168.0.12:8080/admin and delete the user carlos.

The stock checker has been restricted to only access the local application, so you will need to find an open redirect affecting the application first.

View details -> Check stock

Next product 선택 시 결과로 받는 HTTP/2 302 Found 응답 메세지를 통해 리다이렉트 응답임을 확인할 수 있음

이 때의 요청메세지에 GET /product/nextProduct?currentProductId=2&path=/product?productId=3가 포함됨

GET /product/nextProduct?currentProductId=2&path=http://192.168.0.12:8080/admin에 대한 응답

리다이렉트 성공

stockApi=/product/nextProduct?path=http://192.168.0.12:8080/admin/delete?username=carlos로 바꾸어 전송

LAB Solved!

Blind SSRF vulnerabilities

Blind SSRF vulnerabilities occur if you can cause an application to issue a back-end HTTP request to a supplied URL, but the response from the back-end request is not returned in the application's front-end response.

Blind SSRF is harder to exploit but sometimes leads to full remote code execution on the server or other back-end components.

Finding hidden attack surface for SSRF vulnerabilities

Many server-side request forgery vulnerabilities are easy to find, because the application's normal traffic involves request parameters containing full URLs. Other examples of SSRF are harder to locate.

Partial URLs in requests

Sometimes, an application places only a hostname or part of a URL path into request parameters. The value submitted is then incorporated server-side into a full URL that is requested. If the value is readily recognized as a hostname or URL path, the potential attack surface might be obvious. However, exploitability as full SSRF might be limited because you do not control the entire URL that gets requested.

URLs within data formats

Some applications transmit data in formats with a specification that allows the inclusion of URLs that might get requested by the data parser for the format. An obvious example of this is the XML data format, which has been widely used in web applications to transmit structured data from the client to the server. When an application accepts data in XML format and parses it, it might be vulnerable to XXE injection. It might also be vulnerable to SSRF via XXE. We'll cover this in more detail when we look at XXE injection vulnerabilities.

SSRF via the Referer header

Some applications use server-side analytics software to tracks visitors. This software often logs the Referer header in requests, so it can track incoming links. Often the analytics software visits any third-party URLs that appear in the Referer header. This is typically done to analyze the contents of referring sites, including the anchor text that is used in the incoming links. As a result, the Referer header is often a useful attack surface for SSRF vulnerabilities.

HTML

대제목 : tag라고 부름 content content

대문자, 소문자 가리지 않음

문서의 골격

태그 사용 비율

: 문서의 최상단에 위치. 역시 이 문서는 html 문서이다 라는 표현

묶어서 꼭 작성하고 있음. 알아둘 것.

<!DOCTYPE html>
<html>
</html>

html 문서는 두 파트로 나뉨

문서에 대한 정보. 작성자. 문서 제목 등

<!DOCTYPE html>
<html>
    <head></head>
    <body></body>
</html>

한글 사용하려는 경우

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
    </head>
    <body></body>
</html>

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
        <title>이력서</title>
    </head>
    <body></body>
</html>

body 태그 부분

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
        <title>이력서 페이지</title>
    </head>
    <body>
        <h1>Hi</h1>
        <p>content</p>
    </body>
</html>

CSS

footer : 화면 최하단의 안내문

p : paragraph 문단. 일반적으로 쓰는 모든 글을 p

html 파일과 css 파일 분리 -연동하려면

html의 head 태그에 넣음 body에는 화면에 집적적으로 표현되는 컨텐츠만. 컨텐츠 표현을 위한 부수젖ㄱ인 내용은 head에

  <head>
    <meta charset="UTF-8">
    <title>김멋사의 이력서</title>
    <link rel="stylesheet" href="codelion.css">
  </head>

css 파일에서 꾸미기.

footer 꾸미기 footer{ text-align: center; //가운데 정렬 background-color: black; } 내용물 순서는 상관 없음.

css의 기본 형태

Tag{ text-align: center; color: orange; }

One-Time Pad(OTP, 일회용 패드)는 암호학 역사에서 정보이론적으로 완전한 보안(Perfect Secrecy) 이 증명된 대표적인 암호 체계다. 현대의 대부분의 암호 기술이 “현실적으로 해독이 매우 어려운 수준”의 안전성을 목표로 하는 반면, OTP는 이론적으로 공격자가 무한한 연산 능력을 가지고 있더라도 평문 정보를 알아낼 수 없다는 점에서 특별한 의미를 가진다.

다만 이러한 완벽성은 매우 까다로운 조건 위에서만 성립하며, 실제 운영 환경에서는 치명적인 제약이 존재한다 이 글에서는 OTP의 기본 원리와 완전 보안이 성립하는 이유, 그리고 실무에서 널리 사용되지 못하는 배경을 정리한다.

One-Time Pad의 원리

OTP는 평문(Plaintext)과 동일한 길이의 무작위 키(Key)를 사용하여 암호화를 수행하는 방식이다. 현대 컴퓨터 환경에서는 일반적으로 비트 단위의 XOR(Exclusive OR) 연산을 사용한다.

XOR 연산

암호화:

C=P⊕K

• P: 평문(Plaintext)
• K: 키(Key)
• C: 암호문(Ciphertext)

복호화:

P=C⊕K

XOR 연산의 특징상 같은 키를 다시 XOR하면 원래 데이터가 복원된다.

예를 들어

복호화:

0110⊕1100=1010

즉, 동일한 키만 알고 있다면 암호문으로부터 원래 평문을 정확히 복원할 수 있다.

수학자 클로드 샤논(Claude Shannon)은 특정 조건이 모두 충족될 경우 OTP가 Perfect Secrecy를 만족함을 증명했다.

이는 공격자가 암호문만 가지고는 평문에 대한 어떠한 정보도 얻을 수 없음을 의미한다.

OTP의 완전 보안은 다음 조건 위에서 성립한다.

1. 키 길이는 평문과 같아야 한다

키가 충분히 길어야 모든 평문 비트를 독립적으로 가릴 수 있다.

즉:

∣K∣≥∣P∣

짧은 키를 반복 사용하면 패턴이 발생하며 보안성이 붕괴한다.

2. 키는 진정한 무작위(True Random)여야 한다

키는 예측 가능해서는 안 된다.

의사난수(PRNG)가 아닌, 통계적 편향이 없는 진정한 난수여야 하며 공격자가 패턴을 추론할 수 없어야 한다.

3. 키는 단 한 번만 사용해야 한다

“One-Time”이라는 이름 그대로, 동일한 키를 두 번 이상 사용해서는 안 된다.

키 재사용이 발생하면 암호문 간 관계 분석이 가능해지며 OTP의 핵심 보안성이 무너진다.

(4) 키는 완전히 비밀이어야 한다

키를 알고 있는 주체는 송신자와 수신자뿐이어야 한다.

만약 키가 노출된다면 OTP는 일반 평문과 다를 바 없는 상태가 된다.

한계 및 단점

OTP는 이론적으로 완벽하지만, 현실에서는 매우 비실용적이다.

현대 인터넷 보안에서 TLS, AES, RSA 같은 방식이 사용되는 이유도 여기에 있다.

1. 키 분배 문제(Key Distribution Problem)

가장 큰 문제는 키 전달이다.

OTP는 평문과 동일한 길이의 키를 미리 안전하게 공유해야 한다. 예를 들어 1GB 데이터를 암호화하려면 1GB 길이의 무작위 키가 필요하다.

즉, 대규모 통신 환경에서는 키를 안전하게 생성·전달·동기화하는 비용이 지나치게 커진다.

2. 키 저장 비용

대용량 데이터를 처리하는 현대 시스템에서는 데이터 크기만큼의 키를 저장해야 한다.

예를 들어:

1TB 데이터 → 1TB 무작위 키 필요 10TB 데이터 → 10TB 키 필요

이는 운영 효율 측면에서 매우 부담이 크다.

3. 키 재사용 시 보안 붕괴

동일한 키를 두 번 사용하면 다음 관계가 성립한다.

C1⊕C2=P1⊕P2

즉, 키가 상쇄되면서 두 평문 간의 관계 정보가 드러난다.

언어 데이터는 통계적 중복성을 가지므로, 공격자는 이를 기반으로 평문 일부를 추론할 수 있다.

실제 역사적으로도 OTP 키 재사용은 여러 정보기관 암호 체계 붕괴의 원인이 되었다.

사용사례

1. 냉전 시대 정보기관

냉전 시기 스파이 활동에서는 난수가 기록된 종이 패드(Pad)를 사용했다.

암호화 후 사용한 페이지는 즉시 폐기했으며, 여기서 “One-Time Pad”라는 이름이 유래했다.

2. 국가 간 통신

미국과 소련 간 핫라인 같은 최고 수준 기밀 통신에서도 OTP 기반 방식이 연구·활용되었다.

3. 양자 키 분배(QKD)

현대에는 양자역학 기반의 QKD(Quantum Key Distribution)를 이용해 OTP용 키를 안전하게 분배하려는 연구가 진행되고 있다.

OTP 자체는 오래된 기술이지만, 안전한 키 분배 문제를 해결하려는 시도는 여전히 현대 암호학의 중요한 연구 주제다.

https://portswigger.net/web-security/ssrf

SSRF Lab

https://portswigger.net/web-security/all-labs#server-side-request-forgery-ssrf

SSRF란?

Server-side request forgery is a web security vulnerability that allows an attacker to cause the server-side application to make requests to an unintended location.

SSRF 공격

A successful SSRF attack can often result in unauthorized actions or access to data within the organization. This can be in the vulnerable application, or on other back-end systems that the application can communicate with. In some situations, the SSRF vulnerability might allow an attacker to perform arbitrary command execution.

An SSRF exploit that causes connections to external third-party systems might result in malicious onward attacks. These can appear to originate from the organization hosting the vulnerable application.

#1 Lab: Basic SSRF against the local server

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.

사용 툴: Burp Suite

View details 버튼을 눌러 제품 상세 페이지로 이동한다.

제품 상세 하단에 Check stock으로 이동 인터셉트

stockApi=http://localhost/admin로 request 메시지 조작하여 forward

carlos 삭제 시도 실패

이 때의 요청이 https://0ac8004404c2c3d581f9444800900029.web-security-academy.net/admin/delete?username=carlos임을 확인

stockApi=http://localhost/admin/delete?username=carlos로 request 메시지 조작하여 다시 Check stock 인터셉트 및 forward

LAB Solved!

Why do applications behave in this way, and implicitly trust requests that come from the local machine?

• The access control check might be implemented in a different component that sits in front of the application server. When a connection is made back to the server, the check is bypassed.

• For disaster recovery purposes, the application might allow administrative access without logging in, to any user coming from the local machine. This provides a way for an administrator to recover the system if they lose their credentials. This assumes that only a fully trusted user would come directly from the server.

• The administrative interface might listen on a different port number to the main application, and might not be reachable directly by users.

#2 Lab: Basic SSRF against another back-end system

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, use the stock check functionality to scan the internal 192.168.0.X range for an admin interface on port 8080, then use it to delete the user carlos.

사용 툴: Burp Suite

View details에서, Check stock을 intruder로 보내 자동화 공격 수행

stockApi=http://192.168.0.1:8080/에서 1에 대해 Add Payload를 다음과 같이 설정

공격 수행

200 응답 발견

stockApi=http://192.168.0.215:8080/admin 요청 조작

stockApi=http://192.168.0.215:8080/admin/delete?username=carlos 요청 조작

LAB Solved!

127.0.0.1은 네트워크 인터페이스를 거치지 않고 시스템 내부에서 통신하기 위해 예약된 루프백(Loopback) 주소다. 보통 'localhost'라는 호스트명과 매핑되어 사용된다.

• 자기 참조성: 외부 네트워크망에 연결되어 있지 않더라도 운영체제 내부의 네트워크 스택을 통해 자기 자신에게 데이터를 전송한다.

• 용도: 로컬 환경에서의 웹 서버 구동 테스트, 애플리케이션 디버깅, 데이터베이스 연결 확인 등 내부 프로세스 간 통신에 사용된다.

• IPv6 대응: IPv6 규격에서는 ::1이 동일한 역할을 수행한다.

192.168.0.X (Private IP Address)

192.168.0.0/24 대역은 RFC 1918 표준에 의해 정의된 사설 IP(Private IP) 주소 공간이다.

• 접근 제한: 사설 IP는 인터넷 라우팅이 불가능하도록 설계되어 있다. 외부 인터넷 환경에서 해당 주소로 직접 패킷을 전송하면 ISP의 라우터에서 이를 폐기한다.

• 할당 배경: 공인 IP 주소(Public IP)의 고갈 문제를 해결하기 위해 도입되었다. NAT(Network Address Translation) 기술을 사용하여 내부망 기기들은 사설 IP를 쓰고, 외부와 통신할 때만 공인 IP를 공유한다.

• SSRF와의 관계: 외부에서 접근할 수 없는 내부망 시스템이라도, 내부망에 걸쳐 있는 웹 서버가 공격자의 조작된 요청을 받아 대신 통신을 수행할 경우 보안 경계가 무력화될 수 있다.

IP 스캔 범위와 주소 예약 규정

네트워크 대역 스캔 시 192.168.0.1부터 시작하는 이유는 특정 주소들이 특수 용도로 예약되어 있기 때문이다.

192.168.0.0 (Network Address): 해당 네트워크 대역 자체를 식별하는 주소다. 실제 호스트(기기)에 할당할 수 없으므로 통신 대상이 될 수 없다.

192.168.0.255 (Broadcast Address): 네트워크 내의 모든 호스트에게 데이터를 동시에 전송하기 위한 브로드캐스트 주소다. 개별 서비스나 관리자 인터페이스가 존재할 수 없다.

192.168.0.1 (Gateway): 관례적으로 네트워크의 첫 번째 가용한 주소는 게이트웨이(라우터)에 할당된다. 따라서 관리자 인터페이스나 설정 페이지가 존재할 가능성이 가장 높은 지점이다.

따라서 유효한 호스트가 존재할 수 있는 범위는 네트워크 주소와 브로드캐스트 주소를 제외한 .1부터 .254까지다.

1. 계정 관리

2. 서비스 관리

3. 보안 설정

4. 패치 및 로그 관리

OS의 EOS와 EOL

1. EOS(End of Support) - 지원 종료 제품의 공식적인 지원 종료 새로운 취약점 발견 시 제조사는 조치를 취하지 않음.

2. EOL(End of Life) - 수명 종료 운영체제의 수명 자체가 종료

보안의 세가지 요소

TCP/IP 7layer

정보보안 및 개인정보보호 전문가

1. 관련 자격

1.3 개인정보 영향평가 2. 진로 및 준비 방안

tenant tenacy

CSA 클라우드 보안 위협 참고

On-Promise vs Cloud Service

클라우드 컴퓨팅의 책임 공유 모델

• CSP(Cloud Service Provider, 클라우드 서비스 제공업체) - AWS, Azure, GCP, 네이버클라우드 등과 같이 인터넷을 통해 컴퓨팅, 스토리지, 데이터베이스, 네트워크 등 클라우드 기반 리소스를 주문형으로 제공하는 제3자 회사

• MSP(Managed Service Provider, 매니지드 서비스 프로바이더) - 기업의 클라우드 환경 및 IT 인프라 설계, 구축, 운영, 유지보수를 전담하여 관리하는 전문 파트너사

• CSC (Cloud Service Customer, 클라우드 서비스 고객) - 클라우드 서비스를 이용하는 기업이나 개인.

• NFV(Network Functions Virtualization, 네트워크 기능 가상화) - 라우터, 방화벽 등 전용 하드웨어 기반의 네트워크 장비를 가상 머신(VM)이나 컨테이너 등 소프트웨어(VNF)로 구현하여 범용 서버에서 실행하는 기술

• VPC(Virtual Private Cloud, 가상 프라이빗 클라우드) - 퍼블릭 클라우드 제공업체(AWS, NCP 등) 내에서 논리적으로 격리된 사용자 전용 가상 네트워크 공간

• NACL(Network Access Control List) - 클라우드(AWS 등) 및 네트워크 환경에서 서브넷(Subnet) 단위로 들어오고 나가는 트래픽을 제어하는 스테이트리스(Stateless) 방화벽 참고

정보보호관리체계 인증(ISMS-P) VS 클라우드 보안 인증(CSAP)

# 라이브러리 설치
!pip install requests

# 파이썬 코드로 http 요청을 보낼 수 있게 해주는 라이브러리
import requests

# http 요청을 보낼 url
url = "https://www.bookspot.store/"

GET

requests 라이브러리의 get 메소드를 알아보자.

# HTTP GET 요청을 보내는 함수(메소드)
requests.get(url)

->이 주소(url)에 접속해서 데이터를 주세요"라고 서버에 요청하는 코드

❗HTTP GET 웹에서 데이터를 가져올 때 사용하는 요청 방식

구조 설명

response = requests.get(url)

requests - HTTP 요청을 보내는 라이브러리 get - GET 방식으로 요청 url - 접속할 웹 주소 response - 서버가 보내준 응답 객체

response 객체의 속성

response.text        # HTML 코드
response.status_code # 상태 코드 (200이면 성공)
response.headers     # 응답 헤더
response.content     # 바이너리 데이터

내부동작

requests.get(url)

1. 서버에 HTTP GET 요청을 보냄
2. 서버가 그 요청을 처리함
3. 서버가 응답(HTML, JSON 등)을 돌려줌
4. 그 응답을 response 객체로 받음

파라미터 전달

requests.get("https://example.com/search", params={"q": "python"})

실제 요청 주소:

https://example.com/search?q=python

beautifulsoup 라이브러리

# pip install requests beautifulsoup4
!pip install requests beautifulsoup4

.select()

BeautifulSoup 라이브러리에서 CSS 선택자(CSS Selector)를 사용해 HTML 요소를 선택하는 메서드 유사한 것으로는 .select_one(), .find(), .find_all()이라는 것도 있다.

사용법 형식: soup.select(선택자)
지정한 태그, 속성, id 등을 찾아서 리스트로 반환한다.

선택자별 예시

    1) tag
    soup.select('tag')  
        예시)
        soup.select('div') → 모든 <div> 태그를 찾아서 반환

    2) .class
        예시)
        soup.select('.title') → class="title"인 모든 요소를 찾아서 반환

    3) #id
        예시)
        soup.select('#header') → id="header"인 모든 요소를 찾아서 반환

    4) tag.class
        예시)
        soup.select('p.warning') → <p class="warning">인 모든 요소를 찾아서 반환

    5) 부모태그 > 자식태그
        예시)
        soup.select('div > span') → <div> 안에 <span>인 모든 요소를 찾아서 반환

    6)[attr]
        예시)
        soup.select('[href]') → href 속성이 있는 모든 요소 찾아서 반환

    7) [attr="value"]
        예시)
        soup.select('[type="text"]') → 속성 = 값 인 모든 요소를 찾아서 반환

    8) [attr^="value"]
        예시)
        soup.select('[class^="btn"]') → 속성 값이 ~로 시작하는 모든 요소를 찾아서 반환

    9) [attr$="value"]
        예시)
        soup.select('[href$=".pdf"]') → 속성 값이 ~로 끝나는 모든 요소를 찾아서 반환

    10) [attr*="value"]
        예시)
        soup.select('[class*="active"]') → 속성 값에 ~ 포함하는 모든 요소를 찾아서 반환

# HTML을 분석(파싱)하기 위한 라이브러리
from bs4 import BeautifulSoup

# 파일 경로 지정. 현재 폴더 기준(./)
file_path = './html_css/historyofpython.html'

# HTML 파일 열기
# 'r' → 읽기 모드
# encoding='utf-8' → 한글 깨짐 방지
# f.read() → 파일 전체 내용을 문자열로 읽음
with open(file_path, 'r', encoding='utf-8') as f:
    html_doc = f.read()

# HTML 코드 전체가 들어있는 문자열(str)
type(html_doc)
# html_doc

# head 부분 제거
body = html_doc.split('</head>')[1]
response = BeautifulSoup(body, 'html.parser')
response

# BeautifulSoup을 이용해서 파싱하였으므로 bs4.BeautifulSoup 타입
type(response)

selenium

동적 로딩 문제 (JavaScript Rendering 문제)

import requests
url = "https://finance.naver.com/sise/lastsearch2.naver"
response = requests.get(url)
response

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36",
    "Accept-Language": "ko-KR,ko;q=0.9,en;q=0.8",
    "Referer": "https://finance.naver.com/"
}
response = requests.get(url, headers = headers)
response

soup = BeautifulSoup(response.text, 'html.parser')
soup.select('tbody > tr')
soup.select('tbody')

결과로 빈 list 반환됨

1. 정적 초기 로드 (Static Load)

• requests.get()이 가져오는 부분
• 서버가 처음 보내주는 기본 HTML 문서
• 기본적인 HTML 구조, CSS 파일 연결 정보, JavaScript 파일을 불러오라는