PART1. 안전한 소프트웨어 개발방법론


1. 시큐어코딩의 개요

    - 소프트웨어 개발 보안의 필요성을 이해한다.

    - 보안 사고 사례를 이해한다.

    - 다양한 보안 취약점 데이터베이스를 활용할 수 있다.

    - 행정자치부 시큐어코딩 가이드를 활용할 수 있다.

    - 금융 정보 보호 Compliance 이해


2. 개발 보안 방법론

    - 개발 보안 방법론을 이해한다.

    - OWASP CLASP를 이해한다.

    - MS-SDL을 이해한다.

    - 소프트웨어개발 보안 가이드를 이해한다.


PART2. 안전한 소프트웨어를 만드는 시큐어코딩 기법


3. 웹 애플리케이션 보안을 위한 기본 지식

    - 실습환경을 설정한다.

    - HTTP 와 웹 구조 를 이해한다.

    - 인증(Authentication) 과  권한부여(Authorization)을 이해한다.

    - 세션(Session) 과 쿠키(Cookie)를 이해한다. 

    - 인코딩 스키마 를 이해한다.

    - 정규식(regex) 을 이해한다.

    - 로그관리와 로그 분석 방법을 이해한다.


4. 보안취약점 제거를 위한 코딩 기법

    - 입력값 검증 부재로 인한 인젝션 취약점을 이해하고 제거한다. 

    - 세션과 인증관리 취약점을 이해하고 제거한다.

    - 크로스사이트 스크립팅(XSS) 취약점을 이해하고 제거한다.

    - 크로스사이트 요청 위조(CSRF) 취약점을 이해하고 제거한다.

    - 파일 업로드/다운로드 취약점을 이해하고 제거한다.

    - 민감한 데이터 노출 취약점을 이해하고 제거한다.

    - 잘못된 접근 제어 취약점을 이해하고 제거한다.

    - 안전하지 않은 리다이렉트와 포워드 취약점을 이해하고 제거한다.

    - 기타 입력값 검증부재로 인해 발생되는 취약점을 이해하고 제거한다.

    - 잘못된 관리 정책으로 인해 발생되는 취약점을 이해하고 제거한다.


5. 안전하지 않은 코딩 스타일

   - 제대로 처리되지 않은 예외의 위험성을 이해한다.

   - 널포인트 체크없이 사용되는 객체의 위험성을 이해한다.

   - 스레드의 공유데이터에 대한 동기화 처리의 필요성을 이해한다.

   - 캡슐화된 배열의 잘못된 사용을 이해한다.

   - 적절하지 않은 API사용의 위험성을 이해한다.

   - 코드에 남아있는 커맨트, 디버깅코드의 위험성을 이해한다.


PART3.  소프트웨어 보안 강화 기법


6. 오픈소스 보안 프레임워크 활용기법

   - ESAPI 라이브러리를 이해한다.

   - ESAPI 라이브러리의 기본 사용방법을 이해한다.

   - ESAPI 라이브러리를 커스터마이징해 활용하는 방법을 이해한다.


7. 보안약점 및 취약점 진단도구 활용

   - 정적 분석툴을 이용해 소스코드 취약점을 진단한다.

   - 정적 분석 진단 결과를 이해한다.

   - 동적 분석툴을 이용해 소스코드 취약점을 진단한다.

   - 동적 분석 진단 결과를 이해한다.


PART4. 최신 금융 정보 보안 이슈


8. 최신 금융 정보 보안 이슈

   - IT 10대 이슈

   - Non-ActiveX

   - 핀테크

   - 다양한 전자금융 보안 사고 유형

   - 다양한 인증방법으로 보안 강화







블로그 이미지

오픈이지 제로킴

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

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

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

옥션 해킹 사례

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) 자동 업데이트

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

 

 

 

 

 

 

 

 

 

 

 

 

블로그 이미지

오픈이지 제로킴

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

 

 

블로그 이미지

오픈이지 제로킴

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

티스토리 툴바