SQL 인젝션, 예방
Q. SQL 인젝션은 무엇이며, 어떻게 예방할 수 있습니까?
답변: SQL 인젝션은 악의적인 SQL 코드가 데이터베이스 시스템에 주입되어 실행되는 보안 취약점입니다. 이를 방지하기 위해 사용자 입력에 대한 검증, Prepared Statements 또는 파라미터화된 쿼리 사용, 필요한 권한만 부여하고 최소한의 권한 원칙을 따르는 것이 중요합니다.
크로스 사이트 스크립팅(XSS), 예방
Q. 크로스 사이트 스크립팅(XSS)이란 무엇이며, 어떻게 예방할 수 있습니까?
답변: 게시글과 같은 페이지에, 공격자가 악성 스크립트를 삽입하여, 사용자의 정보를 탈취, 악성코드등을 유입시키는 공격을 말합니다. 크로스 사이트 스크립팅(XSS)은 악의적인 스크립트가 사용자의 웹 브라우저에서 실행되어 개인 정보를 도용하는 보안 취약점입니다. 이를 방지하기 위해 사용자 입력에 대한 검증 및 적절한 출력 인코딩, 콘텐츠 보안 정책(CSP) 구현 등이 필요합니다.
인증 VS 인가
Q. 보안을 위한 인증과 인가의 차이점은 무엇입니까?
답변: 인증은 사용자가 누구인지 확인하는 것이고, 인가는 사용자가 시스템에서 무엇을 할 수 있는지 결정하는 것입니다. 인증(Authentication)은 사용자의 신원을 확인하는 과정이며, 인가(Authorization)은 해당 사용자가 특정 자원에 액세스할 권한을 부여하는 과정입니다. 인증은 일반적으로 사용자 이름과 비밀번호를 통해 이루어지며, 인가는 사용자 역할에 따라 작업의 범위를 제한합니다.
대칭키 암호화 VS 비대칭키 암호화
Q. 대칭키 암호화와 비대칭키 암호화의 차이점은 무엇입니까?
답변: 둘은 키의 구조와 괸라 방식에 따라 구분됩니다. 대칭키 암호화는 암호화와 복호화에 같은 키를 사용하며 처리 속도가 빠르고, 비대칭키 암호화는 암호화와 복호화에 서로 다른 키를 사용하며 키 공유 문제를 해결하지만 처리 속도가 상대적으로 느립니다.
대칭키 암호화는 암호화와 복호화에 동일한 키를 사용하는 방식입니다. 이 경우, 키를 안전하게 공유해야 하는 당사자들 사이에서 키 관리가 중요한 문제로 작용합니다. 대칭키 암호화는 일반적으로 빠른 처리 속도를 가지고 있어서 대량의 데이터를 암호화하는 데 적합합니다. 대표적인 대칭키 암호화 알고리즘으로는 AES, DES 등이 있습니다.
반면, 비대칭키 암호화는 공개키와 개인키라는 두 개의 키를 사용합니다. 공개키는 누구에게나 공개되어 있으며, 개인키는 키의 소유자만이 알고 있습니다. 데이터를 암호화할 때 공개키를 사용하고, 복호화할 때는 개인키를 사용합니다. 이 방식은 키 공유 문제를 해결하지만, 대칭키 암호화에 비해 처리 속도가 느립니다. 대표적인 비대칭키 암호화 알고리즘으로는 RSA, ECC 등이 있습니다.
브루트 포스 공격, 대처
Q. 브루트 포스 공격(brute force)이란 무엇이며, 어떻게 방어할 수 있습니까?
답변: 브루트 포스 공격은 키 전수조사 또는 무차별 대입으로도 불립니다. 가능한 모든 조합을 시도하여 비밀번호나 암호화 키를 찾아내는 공격 방법입니다. 브루트 포스 공격을 방어하기 위해 계정 잠금 정책, 복잡한 비밀번호 요구 사항, 로그인 시도에 대한 시간 지연 설정, CAPTCHA 도입, 2단계 인증 사용 등의 방법이 있습니다.
HTTPS와 SSL/TLS 중요성
Q. HTTPS와 SSL/TLS의 관계와 중요성에 대해 설명해주세요.
답변: HTTPS는 웹 통신을 보안하기 위해 사용되는 프로토콜로, HTTP에 SSL/TLS를 결합한 것입니다. SSL이란 보안 소켓 계층으로서 사용자와 서버 간의 데이터를 암호화하는 표준 기술을 의미합니다. TLS는 전송 계층 보안으로 불리며 SSL에 비해 더 발전 및 표준화된 버전이라고 할 수 있습니다. SSL/TLS는 공개키와 대칭키 암호화를 사용하여 데이터를 암호화하고, 인증 및 데이터 무결성을 제공합니다. HTTPS는 데이터의 기밀성과 무결성을 보장하며, 중간자 공격을 방지하는 데 도움이 됩니다.
JWT
Q. 보안 토큰을 사용하는 인증 방식 중 JWT(Json Web Token)에 대해 설명해주세요.
답변: JWT는 JSON 형식의 토큰을 사용하여 클라이언트와 서버 간 인증 정보를 전달하는 방식입니다. JWT는 주로 웹 애플리케이션과 RESTful API에서 무상태 인증을 구현하기 위해 사용됩니다.
JWT는 헤더, 페이로드, 서명으로 구성됩니다
- 헤더(Header): 헤더에는 토큰의 유형과 사용되는 암호화 알고리즘에 대한 정보가 포함되어 있습니다.
- 페이로드(Payload): 페이로드에는 토큰에 포함되는 실제 데이터, 일명 클레임(Claims)이 들어 있습니다. 클레임은 사용자 정보, 발행자, 만료 시간 등과 같은 토큰과 관련된 속성들입니다.
- 서명(Signature): 서명은 헤더와 페이로드를 암호화하여 생성한 값입니다. 서명을 통해 토큰의 무결성을 확인하고 변조 여부를 검증할 수 있습니다.
JWT의 사용 과정은 다음과 같습니다:
- 사용자가 인증에 성공하면, 서버는 사용자의 정보를 바탕으로 JWT를 생성합니다.
- 생성된 JWT는 사용자에게 전달되며, 사용자는 이후 요청에 JWT를 포함시켜 서버에 전송합니다.
- 서버는 전달받은 JWT의 서명을 확인하여 토큰의 무결성을 검증하고, 페이로드에 포함된 클레임을 이용해 사용자의 인증 및 인가를 수행합니다.
JWT의 장점은 별도의 세션 저장소를 필요로 하지 않으며, 확장성이 좋고 여러 서비스 간 인증 정보를 쉽게 전달할 수 있다는 점입니다.
단점은 1) 한번 발급된 JWT는 만료 시간이 될 때까지 유효하므로 토큰 관리에 주의해야 합니다. 이에 대한 해결책으로 Refresh Token을 이용합니다. 2) Payload 정보가 제한적이므로 디코딩하면 누구나 정보를 확인할 수 있기에, 유저의 중요한 정보들은 Payload에 넣을 수 없습니다. 3) 또한 세션/쿠키 방식에 비해 JWT의 길이가 길기 때문에 요청이 많아지면 많아질수록 서버의 자원낭비가 발생할 수 있습니다. 세션/쿠기 방식에 비해서 JWT의 길이가 길기에 요청이 많아질수록 전송시 부하가 증가하여 서버의 자원낭비가 발생할 수 있습니다.
비밀번호의 저장
Q. 애플리케이션에서 사용자 비밀번호를 안전하게 저장하기 위한 방법은 무엇입니까?
답변: 사용자 비밀번호를 안전하게 저장하기 위해서는 다음과 같은 방법을 사용합니다.
- 해시 함수를 사용하여 비밀번호를 해싱합니다. 해싱은 일방향 함수로, 원래 데이터를 복구할 수 없습니다.
- 솔트(Salt)를 추가하여 비밀번호 해시 과정에 무작위 문자열을 삽입합니다. 이는 해시 충돌 공격을 방지합니다.
- 적절한 해시 알고리즘을 선택합니다. 현재는 bcrypt, scrypt, Argon2 등의 알고리즘이 권장됩니다.
- 서버 측에서 비밀번호를 저장하기 전에 HTTPS를 통해 안전하게 전송합니다.
- 비밀번호는 메모리에 저장된 후, 필요한 경우 메모리에서만 사용하고 가능한 빨리 삭제합니다.
'CS, OS, Network' 카테고리의 다른 글
| 서로 다른 데이터 전송 방식, TCP와 UDP (0) | 2023.07.02 |
|---|---|
| 멀티스레딩 (Multithreading)과 멀티프로세싱 (Multiprocessing)의 차이점 (0) | 2023.04.24 |
| 자료구조와 알고리즘 중에서 자주 사용되는 것들 (0) | 2023.04.18 |
| REST API, RESTful API에 대해서 (0) | 2023.04.17 |
| [자바스크립트] HTTP와 HTTPS, 둘의 차이점 (0) | 2023.04.17 |
댓글