보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

옥션 해킹 사례

2015.07.09 01:01

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

KT 홈페이지 해킹사례

2015.07.09 00:49

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

슈퍼쿠키란?

2015.07.08 23:49

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

웹 보안 프로토콜 HSTS, Proposed Standard로 승인2012.10.05

웹 보안 프로토콜인 HSTS (HTTP Strict Transport Security)가 IETF에서 Proposed Standard로 승인됨

※ IETF (Internet Engineering Task Force)는 국제 인터넷 표준화 기구로, 인터넷 운영 프로토콜의 표준과 관련된 사항을 정의함

웹 보안 프로토콜 HSTS가 IETF에서 스티어링 그룹(steering group)으로부터 Proposed Standard로 승인

  • HSTS는 HTTP 세션 하이재킹을 피하기 위해 제안된 프로토콜임
    ※ draft-ietf-websec-strict-transport-sec-14
  • 보안성의 향상을 위한 방안이며, 웹 사이트 연결 시 항상 보안 연결 상태로 접근
    ※ 암호화되지 않은 웹 사이트로 인한 인터넷 하이재킹으로부터 인터넷 사용자들을 보호하기 위해 웹 보안 프로토콜이 제안됨

인터넷 드래프트 문서 상의 HSTS 정책 관련 설명으로는, 보안 연결로만 접근 가능함을 웹 사이트 자신이 선언할 수 있는 메커니즘을 정의하는 것이라고 되어 있음

  • 주요 사항으로는 use cases, HSTS 정책효과, 위협 모델, 요구사항, 적합성과 관련된 요구사항, HSTS 메커니즘을 들 수 있음

정책을 따르는 웹 browser는, 웹 접속 사용자가 URL을 입력 시 “https” 입력을 기억하지 않아도 자동으로 ‘보안 안 되는 링크’에서 ‘보안되는 링크’로 전환되는 것임

이러한 HSTS를 이미 지원하는 사이트 및 서비스의 예로는 PayPal, Blogspot, Etsy, Chrome, Firefox 4, Opera 12 Web browsers가 있음

※ HSTS를 아직 수용하지 않는 사이트 및 서비스 예로는 Microsoft의 Internet Explorer와 Apple의 Safari가 있음

인터넷 사용자들이 많이 이용하는 웹 browser에 대해, 이러한 보안 관련 표준화 연구가 진행되고 있음을 시사

 

[출처]

1. http://news.cnet.com/8301-1009_3-57524915-83/web-security-protocol-hsts-wins-proposed-standard-status

2. http://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport-sec/?include_text=1

 

 

작성 : 침해예방단 연구개발팀

출처: https://www.krcert.or.kr/kor/data/TrendView.jsp?p_bulletin_writing_sequence=1411


블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

REST API의 이해와 설계-#1 개념 소개          http://bcho.tistory.com/953

REST API 이해와 설계 - #2 API 설계 가이드   http://bcho.tistory.com/954

REST API의 이해와 설계-#3 API 보안            http://bcho.tistory.com/955

HMAC을 이용한 REST API 인증 방법 모음     http://bcho.tistory.com/725

 

 

 

블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

X-Frame-Options

자신의 페이지가 Frame안에 들어가는것을 방지하게 한다. 클릭재킹을 막을 수 있다.

X-Frame-Options: DENY (프레임 안에 절대 들어가지 못하게 한다)

X-Frame-Options: SAMEORIGIN (같은 origin일 경우에만 허용한다)

X-Frame-Options: ALLOW FROM hxtp://some-domain.com (특정 origin에서만 허용한다)

 

 

가끔 누군가가 자신의 사이트와 비슷한 도메인을 사서 아무 내용도 없이 자신의 사이트를  전체 크기의 프레임으로 넣어서 접근하는 유저를  엄청 끌어모은 다음, 나중에 갑자기 내용을 바꿔서 표시하는게 가능한데. 이런것을 막을 수 있도록 자신의 페이지가 Frame안으로 들어가는 것을 방지하게 해준다.

 

 

X-Content-Type-Options

 

jpg 확장자로 js파일을 올려 우회를 한 후에 script 태그에 src로 넣는 수법을 방지하는 헤더다. 이 헤더를 넣으면 MIMETYPE과 다르게 사용하지 못하게 한다. nosniff를 넣어주면 활성화가 된다.

 

List of useful HTTP headers

From OWASP
Jump to: navigation, search

This page lists useful security-related HTTP headers. In most architectures these headers can be set in web server configuration (Apache, IIS, nginx), without changing actual application's code. This offers significantly faster and cheaper method for at least partial mitigation of existing issues, and an additional layer of defense for new applications.

Header name Description Example
Public Key Pinning Extension for HTTP The Public Key Pinning Extension for HTTP (HPKP) is a security header that tells a web client to associate a specific cryptographic public key with a certain web server to prevent MITM attacks with forged certificates. Public-Key-Pins: pin-sha256="<sha256>"; pin-sha256="<sha256>"; max-age=15768000; includeSubDomains
Strict-Transport-Security HTTP Strict-Transport-Security (HSTS) enforces secure (HTTP over SSL/TLS) connections to the server. This reduces impact of bugs in web applications leaking session data through cookies and external links and defends against Man-in-the-middle attacks. HSTS also disables the ability for user's to ignore SSL negotiation warnings. Strict-Transport-Security: max-age=16070400; includeSubDomains

X-Frame-Options,

Frame-Options

Provides Clickjacking protection. Values: deny - no rendering within a frame, sameorigin - no rendering if origin mismatch, allow-from: DOMAIN - allow rendering if framed by frame loaded from DOMAIN X-Frame-Options: deny
X-XSS-Protection This header enables the Cross-site scripting (XSS) filter built into most recent web browsers. It's usually enabled by default anyway, so the role of this header is to re-enable the filter for this particular website if it was disabled by the user. This header is supported in IE 8+, and in Chrome (not sure which versions). The anti-XSS filter was added in Chrome 4. Its unknown if that version honored this header. X-XSS-Protection: 1; mode=block
X-Content-Type-Options The only defined value, "nosniff", prevents Internet Explorer and Google Chrome from MIME-sniffing a response away from the declared content-type. This also applies to Google Chrome, when downloading extensions. This reduces exposure to drive-by download attacks and sites serving user uploaded content that, by clever naming, could be treated by MSIE as executable or dynamic HTML files. X-Content-Type-Options: nosniff

Content-Security-Policy,

X-Content-Security-Policy,

X-WebKit-CSP

Content Security Policy requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way browser renders pages (e.g., inline JavaScript disabled by default and must be explicitly allowed in policy). CSP prevents a wide range of attacks, including Cross-site scripting and other cross-site injections. Content-Security-Policy: default-src 'self'
Content-Security-Policy-Report-Only Like Content-Security-Policy, but only reports. Useful during implementation, tuning and testing efforts. Content-Security-Policy-Report-Only: default-src 'self'; report-uri http://loghost.example.com/reports.jsp

 




블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹


SW보안약점 진단 보고서 양식.docx

 

SW보안약점 진단 보고서(XPath 삽입).docx


SW보안약점 진단 보고서(부적절한 예외처리).docx


SW보안약점 진단 보고서(운영체제 명령어 삽입).docx


SW보안약점 진단 보고서(위험한 형식의 파일 업로드).docx


SW보안약점 진단 보고서(크로스사이트 요청위조).docx


SW보안약점 진단 보고서(크로스사이트스크립트).docx


블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

PMD는 16 가지 규칙 세트가 있고 자바 코드의 다양한 일반 문제들을 다룬다.


 규칙

 설명

 Basic

 rulesets/basic.xml

대부분의 개발자들이 동의하는 규칙: catch 블록들은 비어있어서는 안되고, equals()를 오버라이딩 할 때 마다 hashCode()를 오버라이드한다. 

 Naming

 rulesets/naming.xml

표준 자바 네이밍 규약을 위한 테스트: 변수 이름들은 너무 짧아서는 안된다; 메소드 이름은 너무 길어서는 안된다. 클래스 이름은 대문자로 시작해야 하고, 메소드와 필드 이름들은 소문자로 시작해야 한다.

 Unused code

 rulesets/unusedcode.xml

결코 읽히지 않은 프라이빗 필드와 로컬 변수, 접근할 수 없는 문장, 결코 호출되지 않는 프라이빗 메소드 등을 찾기

 Design

 rulesets/design.xml

다양한 좋은 디자인 원리 체크,이를 테면: switch 문장은 default 블록을 갖고 있어야 하고, 심하게 중첩된 if 블록은 피해야 하고, 매개변수들은 재할당되어서는 안되며, 더블(double)이 동일함(equality)과 비교되어서도 안된다

 Import statements  rulesets/imports.xml 

임포트 문장에 대한 작은 문제들 점검. 같은 클래스를 두 번 반입하는 것이나 java.lang에서 클래스를 임포팅하는 것 등

 JUnit tests  rulesets/junit.xml

테스트 케이스와 테스트 메소드 관련 특정 문제 검색. 메소드 이름의 정확한 스펠링과 suite() 메소드가 정적이고 퍼블릭인지 여부

 Strings 

 rulesets/string.xml

스트링 관련 작업을 할 때 발생하는 일반적인 문제들 규명. 스트링 리터럴 중복, String 구조체 호출, String 객체에 toString() 호출하기 등.

 Braces 

 rulesets/braces.xml

for, if, while, else 문장이 괄호를 사용하는지 여부 검사.

 Code size  

 rulesets/codesize.xml

과도하게 긴 메소드, 너무 많은 메소드를 가진 클래스, 리팩토링에 대한 유사한 후보들을 위한 테스트. 

 Javabeans 

 rulesets/javabeans.xml

직렬화 될 수 없는 bean 클래스 같이 JavaBeans 코딩 규약을 위배하는 JavaBeans 컴포넌트 검사.

 Finalizers 

finalize() 메소드는 자바에서 일반적인 것은 아니기 때문에 사용법에 대한 규칙이 비교적 익숙하지 않다. 이 그룹의 검사는 finalize() 메소드 관련한 다양한 문제들을 찾는다. 이를 테면, 비어있는 finalizer, 다른 메소드를 호출하는 finalize() 메소드 finalize()로의 호출 등이 그것이다

 Clone 

 rulesets/clone.xml

clone() 메소드에 대한 규칙: clone()을 오버라이드하는 클래스는 Cloneable을 구현해야 하고, clone() 메소드는 super.clone()을 호출해야 하며,clone() 메소드는 실제로 던지지 않더라도 CloneNotSupportedException을 던지도록 선언되어야 한다.

 Coupling  

 rulesets/coupling.xml

클래스들간 과도한 커플링 표시 검색. 지나치게 많은 임포트, supertype 또는 인터페이스가 충분한 곳에서 subclass 유형 사용하기, 너무 적은 필드, 변수, 클래스 내의 리턴 유형 등.

 Strict exceptions 

 rulesets/strictexception.xml 

예외 테스트: 메소드는 java.lang.Exception을 던지도록 선언되어서는 안되고, 예외는 플로우 제어에 사용되어서는 안되며, Throwable은 잡혀서는 안된다.

 Controversial 

 rulesets/controversial.xml

일부 PMD 규칙들은 유능한 자바 프로그래머가 받아들일 수 있는 것들이다. 하지만 어떤 것은 논쟁의 여지가 충분하다. 이 규칙 세트에는 좀더 의심스러운 검사들이 포함되어 있다. 변수에 null 할당하기, 메소드에서 온 다중의 리턴 포인트 sun 패키지에서 임포팅 등이 포함된다

 Logging 

 rulesets/logging-java.xml

 java.util.logging.Logger를 위험하게 사용하는 경우 검색: 끝나지 않고 정적이지 않은 logger와 한 클래스에 한 개 이상의 logger 등


Inspection 사용자룰 활용하기

http://www.egovframe.kr/wiki/doku.php?do=export_xhtml&id=egovframework%3Adev%3Aimp%3Ainspection%3Acustomrule#inspection_사용자정의_룰_활용

블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

 

일반 사용자들도 자신이 사용하는 브라우저 보안 설정을 통해 사용자 환경에 대한 보안을 강화할 수 있다.

크롬의 경우 웹 사이트에 접속할 때 웹사이트로 부터 사용자와 컴푸터를 보호해주는 기능이 포함되어 있다세이프 브라우징, 샌드박스, 자동업데이트와 같은 기술을 사용하여 피싱이나 악성코드 공격으로 부터 사용자를 보호한다.

 

(1) 세이프 브라우징
악성코드나 피싱이 포함되어 있는것으로 의심되는 사이트에 접속하는 경우 경고메시지를 표시한다.
"
다음 웹사이트에 멜웨어가 있습니다.", "위험: 멜웨어주의", "신고된 피싱 웹사이트 주의
",
"
방문하려는 사이트에 유해한 프로그램이 있습니다." 와 같은 메시지가 표시된다.

 

피싱 및 멜웨어 경고 사용중지 설정
Chrome
메뉴 > 설정 > 고급설정표시 > "개인정보" 에서 "피싱 및 악성코드 차단 사용" 체크박스
선택 취소

 

<참고> 멜웨어란?

알지못하는 사이에 컴퓨터에 설치되는 유해하거나 원치 않는 소프트웨어를 멜웨어라고 한다.

 

 

 

(2) 샌드박스

악성코드가 컴퓨터에 자동으로 설치 되지 않도록 하며, 하나의 브라우저 탭에서 발생한 상황이 다른 브라우저 탭에 영향을 미치지 못하게 한다.

 

(3) 자동 업데이트

크롬은 주기적으로 최신보안 업데이트를 확인하여 최신 보안 기능 및 수정사항이 자동으로 업데이트 된다.

 

 

 

 

 

 

 

 

 

 

 

 

블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

 

 

블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

실습교육참고: https://goo.gl/nhjiSD

설문지링크: https://goo.gl/GrNiVM


1. SecureCoding.zip 파일을 c:\ 에 압축해제한다.


2. Window_XP_client.zip 파일을 c:\VM\ 에 압축해제 (C:\VM 디렉토리 생성후)


3. cmd 실행
c:\> netstat -ano 
3306(MySQL), 8080(Tomcat) 포트가 오픈되어 있는지 확인한다.
만약 2개의 포트가 사용중이면, 해당 프로세스를 종료한다.

taskkill /pid 1234   <-- 1234는 프로세스 ID 이며, 

                               netstat 실행결과의 마지막 컬럼에 표시된다.

 
5. VMWarePlayer  또는 VMWare Workstation 이 설치되어 있는지 확인한 뒤, 없으면 VMware-player-x.x.x-xxxxx.exe를 실행하여 설치한다.


== 웹 서버 실행하기 == 


6. c:\SecureCoding 폴더로 이동하여 start_lab.bat 파일을 실행한다.

 -> 실행하게 되면 먼저 MySQL DB가 실행되며, 포트를 허용하겠는가 하는 알림창이 뜨면, 허용한다. 다음 이클립스가 구동되며 이때도 java 실행을 허용하겠는가 알림창이 뜨면 허용한다.


7. 이클립스 왼쪽 workspace에 있는 openeg 프로젝트를 선택하고, 오른클릭

Run As > Run on Server를 선택하여 서버를 실행한다.


8. 이클립스 왼쪽 workspace에 있는 WebGoat프로젝트를 선택하고, 오른클릭 Run As > Run on Server를 선택하여 서버를 실행한다.

로그인 알림창이 뜨면    아이디: guest    패스워드: guest  를 입력하여 시스템에 접속한다.


  

== 클라이언트 실행하기 == 

 

9,  바탕화면에 설치된 VMWare Workstation Player를 실행한다.


10. Open Virtual Machine 버튼을 클릭한다.


11. 탐색기에서 Window_XP_Client 압축이 해제된 디렉토리에서 window_professional.vmx 파일을 선택한다.


12. 가상머신이 로드되면 [ Start Virtual Machine ] 을 클릭하여 시작한다.

window 구동이 완료되면, Administration 계정의 비밀번호 "client00"을 입력하여 로그인 한다.



== 클라이언트에서 서버 접속하기 == 


13. 가사머신의 바탕화면에 있는 Paros를 실행한다.

Paros는 Local Proxy 서버로 사용되며,  IP: 127.0.0.1   PortNO: 8082 로 설정되어 있다. <-- Paros의 옵션메뉴에서 확인 한다.


14. 브라우저(explorer)를 실행한다.

브라우저에 프록시를 경유해서 서버에 연결되도록 설정한다.

설정> 고급 > 연결 > LAN설정 에서 Proxy서버 설정을 IP: 127.0.0.1   PortNO: 8082 로 설정한다.


15. 이미 구동되어 있는 서버 http://192.168.xxx.xxx:8080/openeg/ 로 연결해 본다.  <-- 정상적으로 프록시서버가 연결되어 있으면 프록시의 History탭에 오고가는 메시지를 확인할 수 있다.







실습교육참고: https://goo.gl/nhjiSD

설문지링크: https://goo.gl/GrNiVM

블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

마이크로소프트사는 SDL(Secure Develop Lifecycle) 통한 소프트웨어 개발 프로세스를 개선함으로써 시스템 취약점을 획기적으로 줄일 수 있었음




Pre-SDL 단계


소프트웨어 개발팀의 구성원들이 보안의 기초와 최신 보안 동향에 대한 정보를 매년 1회 교육을 받을 수 있도록 한다.  보안 교육은  다음 내용을 포함한다.

   - 시큐어 설계

   - 위협모델링

   - 시큐어 코딩

   - 보안 테스팅

   - 프라이버시


요구사항 단계


신뢰성 있는 소프트웨어를 구축하기 위한 기본 보안 요구사항과 프라이버시 요구사항을 정의한다.  필수항목으로는

   - SDL 방법론 적용 여부 결정

   - 보안책임자(Security Advisor) 선정

   - 보안 팀(Security Champion) 선정

   - 버그 리포팅 도구 정의

   - 보안 버그 경계 (security bug bar) 정의

   - 보안 위험 평가

   - 보안 계획서 작성

   - 버그 추적 시스템 정의  


설계 단계


구현에서부터 배포에 이르는 동안 수행해야 하는 작업 계획을 수립하는 단계이다.

 

   - 보안 설계 검토

   - 방화벽 정책 준수

   - 위협 모델링

   - 위협 모델 품질 보증

   - 위협모델 검토 및 승인

   - “보안 설계서” 문서 작성

   - 보안 디폴트 인스톨 실행

   - 모든 샘플소스코드의 보안검토 수행,

   - 안전하지 않은 함수와 코딩 패턴 알림

   - 설계변화요구에 관한 보안관련 사항 문서화

   - 위협모델을 통해 찾아진 취약성을 위한 작업 목록 작성


공격표면(attack surface) 계획수립 :  공격표면이라는 개념적으로 정보 및 금융자산, 지적 재산, 또는 비즈니스 수행 역량에 존재하는 잠재적 공격 지점을 확인하는 과정을 의미한다. 위협 모델링에서 공격 표면 관리는 일종의 네트워크, 애플리케이션, 시스템등 공격자들이 데이터나 정보를 수집하는 지점을 확인하고 공격을 예방하는 것



구현 단계


보안 및 프라이버시 문제점을 발견하고 제거하기 위해 개발 best practice를 수립하고 따르도록 한다.

   - 최신버전의 빌드 도구 사용

   - 금지된 API 사용 회피

   - ‘Execute' 허가를 통한 SQL 안전하게 사용

   - 저장된 프로시저에서 SQL 사용

   - 안전하게 소프트웨어를 사용하기 위해 필요한 사용자 정보 식별

   - 사용자 중심의 보안 문서 계획

   - 보안 형상관리에 관한 정보 생성

   - 자동화된 금지 API 변환 실행

   - 프로젝트 팀 전체와 모든 모범사례와 정책에 대해 정의, 문서화, 토론등



검증 단계


코드가 이전 단계에서 설정한 보안과 프라이버시를 지키는지  보안 및 프라이버시 테스팅과 보안 푸쉬(security push), 문서 리뷰를 통해 확인한다. 보안 푸쉬는 팀 전체에 걸쳐 위협 모델 갱신, 코드 리뷰, 테스팅에 초점을 맞춘 작업이다.

   -  커널-모드 드라이버를 위한 테스팅 완료

   -  COM 객체 테스팅 수행

   - 인증된 사이트 크로스 도메인 스크립팅을 위한 테스팅

   - 애플리케이션 검증 테스트 수행

   - 파일 fuzzing 수행

   - 위협모델 검토 및 수정등

    - 보안 테스팅 계획 완료

    - 침투 테스팅 수행

    - 시큐어 코드 검토

    - 보안 푸쉬를 시작하기 전 모든 코드에 대한 우선순위 결정

    - 보안 문서 계획서 검토등


참고: https://www.microsoft.com/en-us/sdl/



[참고] 위협모델링


위협모델링은 자산에 피해를 줄 수 있는 위협위험도

계산하고, 위협을 완화하기 위한 대응 조치를 파악한다.

개발보안 방법론에 따라 분석단계,또는 설계단계에게 수행하도록 권장하고 있다.

요구사항정의서가 도출되고, 설계에 들어가기 중간단계에 수행하는 것이 적절하다.


1단계: 위협 모델링을 수행하기 위한 보안 팀 구성


2단계: 애플리케이션 분해 작업 수행


3단계: 위협도출

             Spooping Identity(신분위장)

             Tampering with data(데이터변조)

             Repudiation(부인)

             Information disclosure(정보유출)

             Denial of Service, Dos(서비스거부)

             Elevation of privilege(권한상승)


4단계: 도출된 위협에 대한 위험도 계산

           Damage potential(예상피해)

             Reproducibility(재현확률)

             Exploitability(공격용이도)

             Affected users(영향을 받는 사용자)

             Discoverability(발견용이성)


5단계: 대응기법선택

           문제점을 무시한다.

             문제점을 사용자에게 알린다.

             문제점을 제거한다.

             문제점을 고친다.


6단계: 대응기술 선택

           도출된 각 위협(STRIDE)을 제거하기 위해

             위협요소별 대응기술을 고려한다.

           S : 적절한인증,Keberos authenticationm, PKI시스템, 전자서명

           T : hash, ACLs, Message Authentication

           R : 전자서명, 감사로그

           I  : privacy-enhanced 프로토콜, 암호화, ACLs

           D : ACLs, 필터링, Throtting, QoS

           E : 최소권한으로 실행, group or role membership, input validation



소프트웨어 개발 보안 방법론을 적용하여 프로젝트를 수행  하는 경우 취약점이 대폭 감소하여 보안패치와 같은 유지보수 비용이 확연하게 감소하였다.



블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

티스토리 툴바