우선, 고객님과 똑같은 고생을 해본 개발자로써 반갑기 그지 없습니다~ ^^페이지 이동 구조로 되어 있는 웹사이트의 크롤러를 만들때 Web crawler를 Selenium WebDriver를 이용하면 만들기 간편합니다. 그런데 이런 WebDriver들은 서버의 브라우저와 브라우저 드라이버를 통해서 대상 웹사이트를 크롤링하기 때문에 호스트가 필요하고 localhost를 사용하게 됩니다. 그러다 보니 기본적으로 socks4 127.0.0.1 9050 를 설정값으로 사용하는 proxychains와 충돌나면서 denied 또는 timeout […]
긴급하게 중요한 정보들만 공유합니다. 관련 취약점들이 계속 나올수 있기 때문에 지속적으로 모니터링해서 적합한것들을 사용하세요~ 이 취약점의 원격 공격 원리는? (간단한 이해) – https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j– https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/ 이 취약점이 어떤 제품들에게 노출되어 있는가? (취약한 제품 목록) – log4j를 사용하는 제품들이 진짜로 상당히 많다는 것을 알 수 있을 것입니다.https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592 이미 공격을 당했는지 어떻게 알 수 있는가? (침해 여부 점검용 python 프로그램)
Microservice Architecture의 보안 요구사항 당사가 금융회사들을 중심으로 Microservice Architectur기반의 정보시스템 개발에 대한 개발보안 컨설팅들을 수행하면서 6개 영역 48개의 표준 보안요구사항을 정리하였다. Microservice Architecture는 별도의 Service Port를 제공하는 Docker Container로 다수의 Microservice들을 구현하기 때문에 인증, 접근권한, 로깅, 암호화, 개인(신용)정보보호 등 거의 모든 부문의 정보보안 아키텍처를 다른 시각에서 재조명 해봐야 한다. 외국은행의 경우 약 1,500개의 Microservice로 구성된
말씀하신 내용에 따르면 외부망에서 진행하는 외부 모의해킹 진단 수행 결과로 짐작됩니다.진단자는 외부망에 위치하여 대상 시스템을 외부자의 입장에서 진단을 수행하는 외부 모의 해킹 진단, 또는 External Penetration Test 로 판단됩니다.그러면, 이 진단자(외부망에 위치)와 대상 웹사이트의 사이에는 어떤 기술 요소(시스템)이 존재할까요?기업이나 조직의 인프라 구성에 따라 다르겠지만, 일반적으로 아래와 같은 기술 요소들이 있을 것입니다. [| 진단자 |] –
간혹, 모바일 앱이나 웹사이트 모의 해킹 진단을 하다 보면, 서버의 공개키를 이용해서 데이터를 암호화하지 않고 임의의 대칭키 방식으로 데이터를 암호화해서 서버에 전송하는 경우가 있습니다. 대부분의 대칭키 방식은 클라언트에 키가 있기 때문에 이를 복호화하는 것은 시간 문제일 뿐입니다. 어떤 경우에는 그 키를 그냥 base64로 인코딩하거나 shift기법 또는 XOR로 쓰는 경우도 있어서 공격자 관점에서 복호화가 아주 쉬웠던
Websocket 구현 시 고려해야 하는 보안 사항 1. Authentication mechanism비인가자의 Websocket접근을 방지하기 위하여 적절한 인증 메커니즘을 적용한다. 2. Access Control인가된 사용자 또는 디바이스만 접근할 수 있도록 적절한 방법으로 접근 통제를 적용한다. 3. Session ManagementSession은 비인가된 접근을 방지하기 위하여 적절하게 관리되어야 한다. 특히, Websocket의 disconnections, timeouts, session검증 등에 대한 적절한 처리가 적용한다. 4. Transaction EncryptionClient와 Server간
대표적인 핀테크 서비스로 현재 금융권 오픈뱅킹 사업이 있습니다. 오픈뱅킹 서비스를 포함한 핀테크 사업은 필수적으로 전자금융거래가 발생하기 때문에 전자금융거래법 상의 전자금융감독규정을 준수해야만 합니다.또한, 최근 오픈 API를 활용한 금융서비스가 활발히 도입되면서 금융당국에서는 관련 가이드라인도 배포하는 등 기술적인 보안위험을 차단하기 위해 노력하고 있습니다. (1) 금융감독원이나 금융보안원과 같은 대표적인 금융관련 보안당국의 가이드라인 또는 기준 검토(2) 해당기관의 조직도 및 연락처를
전자금융감독규정 제14조의 2(클라우드컴퓨팅서비스 이용 절차 등) – 시행 2019.01.01은 아래와 같이 정의하고 있습니다. 제1항) 금융회사 및 전자금융업자가 클라우드컴퓨팅을 이용하고자 하는 경우에는 아래 절차를 수행해야 한다 제3,4항) 시스템이 고유식별정보 또는 개인신용정보를 처리하거나 전자금융거래의 안전성과 신뢰성에 중대한 영향을 미치는 경우 아래의 서류들을 영업일 7일 이전에 금융감독원장에게 보고해야 한다. 제6항) 아래의 변경사항 발생시 영업일 7일 이내에 해당 사항,
1. 보안 고려 사항 2. UUID생성 Python 예제 # 예제 코드 -1 uuid4()함수를 이용한 랜덤 UUID 생성 예제 코드 import uuid new_uuid = uuid.uuid4() print(f”The generated UUID is : {new_uuid}”) # 예제 코드 -2 secrets모듈을 이용한 랜덤 UUID생성 예제 코드 import secrets def generated_uuid(): return secrets.token_hex(16) # 예제 코드 -3 OWASP의 ESAPI 프레임워크를 이용한 예제
보안 고려사항 1. 통신구간 암호화를 사용한다.– 통신상의 도청, 변조 공격을 방지하기 위하여 Client와 OAuth server간의 모든 통신구간을 HTTP/TLS로 암호화를 적용한다.(TLS1.2이상)– MiTMA(main in the middle attack)을 방지하기 위해서는 OAuth Server의 인증서를 Client에서 검증할 수 있도록 E2E암호화를 적용한다. 2. 안전하게 Client Secrets(Client ID에 대한 비밀키)을 저장한다.– Client secrets는 client측에 안전하게 저장되어야 하며 평문으로 전송되거나 코드내에 포함되어 있어서는
