SW 개발이 좋은 사람

PMD는 정적인 소스코드 분석 도구로

자세한 설치와 사용법은 한국인터넷진흥원에서 제공하는

"공개SW를 활용한 소프트웨어 개발보안 검증가이드"의 "4장 PMD 사용방법"을 따라 한 후 다음 내용을 읽기 바란다.

게시판 예제를 대상으로 PMD를 실행하면 다음과 같은 결과를 얻게 된다.

화면 하단의 "Violations Overview"에서 오류를 두번 클릭하면 해당 오류 코드로 이동한다.

게시판에서 AvoidCatchingGenericException오류가 발견되었다.

이 오류는 일반적인 예외처리(Exception)을 하지 말라는 것으로

TransactionException 등과 같이 구체적으로 작성하면 된다.

예외 처리에 대한 자세한 설명은 검색해 보거나 이 블로그를 참고하기 바라고

위 결과와 관련하여 한가지를 더 처리한다.

board4.xml의 게시판 글쓰기 처리를 하는 SQL인 insertBoard4에서 사용하는 필드명을 틀리게 작성한다.

여기에서는 BRDTITLE1으로 지정했다.

board4.xml

웹 브라우저에서 게시글을 작성한후 저장하면(http://localhost:8080/board/board4Save) 다음과 같은 오류가 발생한다.

그림에 나타난 것과 같이 사용된 SQL문과 경로 정보등이 사용자에게 노출되어 보안에 문제를 야기하게 된다.

따라서 PMD에서는 잡히지 않았지만 예외 처리를 바꿔야 한다.

흔히 사용되지만 다음과 같은 코드는 사용하지 않는 것이 좋다.

printStackTrace대신에 System.out.println(e), throw e 등도 사용하지 않는 것이 좋다.

예제에 사용하지 않았지만

이러한 오류를 오류 메시지를 통한 정보노출이라고 하여 PMD에서는 AvoidPrintStackTrace로 설정하여 오류로 출력해 준다.

즉, 앞서 PMD에서 지적된 Avoid catching generic exceptions과 같이 정리하면

다음과 같이 구체적인 예외 처리를 하고 메세지는 직접 출력하는 것이 좋다.

SQL문을 틀리게 작성했기 때문에 BadSqlGrammarException으로 구체적으로 명시하고

오류메세지를 직접 출력한다.

board4Svc.java의 insertBoard 함수에서 위와 같이 수정하고 실행하면

로그에는 오류가 출력되지만 웹 사이트에서는 오류 없이 리스트로 넘어간다.

(사용자에게 글 저장이 안된다는 연락을 받을 수 있다.)

정리하면 다음과 같이 사용하는 것이 좋다.

BadSqlGrammarException는 일부러 발생시킨 오류이기 때문에 TransactionException으로 처리한다.

아니면 try 문을 사용하지 않고 처리해도 된다.

Board41Svc.java

오류로 잡히지 않았지만 모든 메소드에  throws Exception(위 코드의 굵은 글자) 가 사용되고 있다.

Java 관련 코드에서 일반적으로 사용하는 것이지만 제거하는 것이 좋다.

앞서 언급된 일반적인 예외처리는 지양하는 것이 좋고, 

예외 처리를 Exception으로 던지고 마는 것이 아니라

try문으로 보다 구체적으로 처리하는 것이 추천되기 때문이다.

따라서 Board41Ctr.java와 Board41Svc.java의 throws Exception를 모두 제거하는 것이 좋다.

ex.toString()도 가급적 사용하지 않는 것이 좋지만

개발시 정확한 오류 메시지를 확인하기 위해 사용하였다.

언급한 예외 처리는 Eclipse에서 기본적으로 생성해 주는 것으로 무심코 넘기는 경우가 많은 데,

최근 공공기관, 대기업 등에서 보안에 대한 관심이 높아지면서

상용 도구를 이용하여 이상의 내용보다 더 많은 내용을 점검하고 있다.

따라서 공개 S/W를 이용하여 이러한 사항들을 미리 처리하는 것이 좋을 것이다.

마지막으로

이러한 조치를 다한 후에 web.xml에서 에러 페이지 처리를 해줘야 한다.

설정 방법은 검색해 보거나 다음 블로그를 참고하면 된다.

http://artrix.tistory.com/383

http://hyeonstorage.tistory.com/98

이러한 조치를 통해 다음 그림과 같이 사용자에게 불필요한 정보가 노출되지 않도록 해야 된다.

다음과 같이 web.xml에서 Exception 오류에 대한 오류 웹 페이지 지정을 처리를 해주면 되고

404, 500등의 오류도 처리해 주는 것이 좋다.

board\src\main\webapp\WEB-INF\web.xml

이상의 내용은 사이트 품질과도 관련되지만

정보 노출의 의미에서는 웹 사이트 보안과도 관련이 있는 내용으로 잘 숙지해서 처리해야 한다.

프로그램을 개발하다 보면 여러 가지 도구들이 필요하다.

여러 사람이 같이 작업하기 때문에 코딩규칙을 정하고 확인하게 된다 (CheckStyle).

사람이 하는 일이라 잠재적인 결함이 발생할 수 있다 (FindBugs).

웹 페이지의 접근성을 진단하는 Open WAX (Open Web Accesiblilty eXtension)도 필요하다.

개발이 완료된 후에는 웹 사이트의 성능을 확인해야 실제 서비스를 제공할 때 문제를 최소화 할 수 있다 (JMeter). 

또, 악의적인 접근에 대한 보안 테스트도 필요하다 (OWASP TOP 10).

자바 소스 코드를 분석하여 불필요한 부분을 찾고 성능을 높이도록 도와주는 도구인 PMD도 있다.

이와 관련된 설치및 자세한 사용법은 한국인터넷진흥원 사이트에서 제공한다.

이외의 소프트웨어 개발보안가이드, 모바일 서비스 보안 가이드등도 제공하니 읽어보면 많은 도움이 될 것이다.

이러한 항목에 대해서 차후에 천천히 정리하려고 했는데

얼마 전 어떤 분의 지적이 있어 

개발 중간에 필요한 CheckStyle과 FindBugs를 먼저 정리했다.

이외에도 품질 검증과 관련된 다양한 도구는 공개 SW포털(OSS) 등에서 확인할 수 있다.

본 내용은 (주)다모넷 김종호 차장이 인터넷 자료를 토대로 작성한 사내 문서에서 발췌한 것이다.

- Checkstyle는 Java의 소스코드(.java파일)의 기술형식 코딩규약에 준하고 있는지를 체크하는 오픈 소스의 정적 해석 툴입니다.

- 정적 해석(Static program analysis):  실제 실행 없이 컴퓨터 소프트웨어를 분석하는 것을 말하는 것으로, 자동화된 툴을 사용한 분석, 또는 코드 검토 등의 활동을 의미합니다.

ㄱ. 소프트웨어 설치

- 이클립스에서 Software 설치 창으로 이동한다.

- 이클립스 실행 > Help > Install New Software

ㄴ. 업데이트 사이트 주소추가

- 주소 명: http://eclipse-cs.sf.net/update/

ㄷ. 설치 플러그인 선택 - Checkstyle

ㄹ. 설치과정 확인

Eclipse가 재시작되면 설치가 완료된 것이다

Eclipse 메뉴에서 Window > Show View > Other를 선택한다.

위 그림과 같이 Checkstyle > Checkstyle violations를 선택하고 OK한다.

Eclipse 하단에 Checkstyle violations 탭이 추가된 것을 확인할 수 있다.

본 게시판 예제의 프로젝트를 선택하고 마우스 오른쪽 버튼을 눌러 Properties를 실행한다.

Checkstyle에서 "Checkstyle active for this project"를 체크하고 OK를 선택한다.

다음 그림과 같이 규칙에 어긋난 내용들이 나타나게 된다.

먼저 하단의 "Checkstyle violations" 뷰를 보면 프로젝트의 오류 리스트들이 종류별 정리되어 나타난다.

이 규칙은 위 그림에서 "Google Checks"을 선택했기 때문에 나오는 것으로 상세한 규칙은 구글 사이트나 번역 자료를 확인해 보길 바란다.

위 오류를 해결하는 방법은 2가지가 있다.

- 첫 번째 방법은 오류대로 수정하는 것이고,

- 두 번째 방법은 규칙을 수정하는 것이다.

규칙을 수정하는 이유는 현재 사용한 규칙이 구글의 방식이고

다소 타이트하게 구성되었기 때문에 각자에 맞게끔 수정해서 사용하는 것이 좋다.

개인적으로 예제로 사용된 구글 규칙은 Java 어플리케이션 규칙으로

웹일 경우는 다소 다르게 적용하는 게 좋을 것 같다.

Java 웹도 클래스 등을 사용하고 상속의 개념을 이용하지만 약하게 사용되고

특히 Spring은 클래스 개념이 조금 무시되기도 한다

(Spring은 다른 패키지 경로에 동일한 클래스가 있으면 오류 발생).

오류 수정을 위해
- 현재까지 진행된 보드(board1~4)를 수정하면 제공된 예제가 모두 정상이 되기에

  board4를 복사해서 board41로 만든다.

  SQL, JSP는 제외하고 Java 파일만 복사해서 수정해 본다.

- 규칙도 구글 원본을 수정하기 보다는 복사해서 별도의 규칙 파일을 만들어서 사용한다.

먼저, board4를 복사해서 board41로 만들고 클래스도 동일하게 바꾸어 준다.

다음으로 Eclipse의 windows > Preferences 메뉴를 실행한다.

새로운 규칙 이름을 My Check로 입력하고 OK한다.

다음으로 프로젝트(board)를 선택하고 마우스 오른쪽 메뉴를 눌러서 컨텍스트 메뉴를 실행한다.

메뉴에서 Properties를 실행한후 왼쪽 트리에서 Checkstyle을 선택한다.

화면 중앙의 콤보 박스(Simple)에서 My Checks를 선택하고 OK 한다.

위 그림에서 오른쪽에 있는 Configure 버튼을 기억해야 한다.

Checkstyle violations 뷰에서 Marker count 컬럼명을 클릭하여 오류가 많은 순으로 정렬한다.

오류의 수는 진행 상태에 따라 개수가 바뀔 수 있다.

1. Line contains a tab character가 557회 발생했다.

탭(Tab) 키 사용을 금지하는 것으로 리스트에서 해당 항목을 더블 클릭한다.

831개의 오류가 난 파일들이 나오게 된다. 

확인을 위해 앞서 만든 board41Ctr.java를 찾아서 다시 더블 클릭하면 다음 그림과 같은 화면이 나온다 (아무 파일을 해도 상관없다).

소스 코드 앞에 돋보기에 마우스를 대면 오류를 확인할 수 있다.

Eclipse의 바꾸기(Repalce)를 이용하여 탭을 공백(Space) 4개로 바꾸어 주면 돋보기들이 사라진다.

board41Svc 도 같은 방식으로 수정해 준다.

남는 돋보기는 다른 오류이니 넘어가도 된다.

앞서 오류가 난 39라인의 돋보기를 보면 오류명이 바뀌어 있다.

Checkstyle violations 뷰에서 board41Ctr.java 파일이 사라지고 없다.

탭키는 자주 사용되는 것으로 탭키를 누르면 공백으로 바꾸어 주는 것이 좋다.

구글에서 "eclipse tab to space"로 검색해서 방법을 익혀두면 좋을 것이다.

2. ‘X’ have incorrect indentation level X, expected level should be X가 467회 발생했다.

더블 클릭해서 상세 정보를 보면 들여쓰기 오류인 것을 알수 있다.

2번째(Level 2)에 있어야 하는데 4번째(Level 4)에 있다는 의미로 게시판 예제는 4개씩 들여썻고,

구글은 2칸씩 들여쓰기하고 있다.

프로젝트(board)를 선택하고 마우스 오른쪽 메뉴를 눌러서 컨텍스트 메뉴를 실행한다.

Properties > Checkstyle를 선택하고 Configure 버튼을 클릭하여 다음 화면을 실행한다.

왼쪽 트리에서 Miscellaneous를 선택하고 Indentation의 체크를 해제한뒤 OK 한다.

‘X’ have incorrect indentation level X, expected level should be X뿐 아니라 

‘X’ child have incorrect indentation level X, expected level should be X (353회)도 사라지고 없다.

둘다 들여쓰기 규칙을 의미하는 것으로 위 설정으로 해당 규칙 적용이 되지 않아서 사라졌다.

3. Import statement for 'X' is in the wrong order. Should be in the 'X' group, expecting not assigned imports on this line. (65회)

이것은 Java의 import에 대한 규칙으로 구글 명명 규칙 번역 자료에 상세하게 나와 있다.

이 규칙도 다음 그림과 같이 Properties > Checkstyle | Configure > Import에서 "Custom Import Order"의 체그를 해제한다.

4. Missing a Javadoc comment가 29회 발생했다.

주석에 대한 것으로 현재는 //로 되어 있는 것을 그림과 같이 /* */로 작성해야 한다.

다만 지켜야 할 것이 시작시 /** 이고 문장은 반드시 점(.)으로 끝나야 한다.

이 주석들은 모아져 Javadoc(API 문서)으로 생성되는데 생성 방식은 구글링 해보길 바란다.

개인적으로 웹 프로그래밍에 Javadoc(API 문서)이 필요한 지와 사용여부에 의문이 있지만

주석은 꼭 필요한 것이라 함수의 파라메터에 대한 설명등 보다 많은 주석을 작성하는 것이 좋다.

5. Name 'X' must match pattern 'X'가 19회 발생했다.

상세 화면에서는 Type name 'board41Ctr' must match pattern '^[A-Z][a-zA-Z0-9]*$'.로 나온다.

이것은 정규식을 사용한 것으로 클래스명의 첫 글자를 대문자로 하라는 것이다.

board41Ctr, board41Src, boardVO를 Board41Ctr, Board41Src, BoardVO로 바꾸어 준다.

이것은 Java의 기본 명명 규칙으로 클래스명은 대문자로 시작하고

인스턴스는 소문자로 시작해서 둘을 구분짓는 것이다.

상 세 정보에서 이외에도Local variable name 'p' must match pattern '^[a-z][a-z0-9][a-zA-Z0-9]*$', Parameter name 'Filename' must match pattern '^[a-z][a-z0-9][a-zA-Z0-9]*$'. 가 있다.

해당 코드에서 돋보기를 보면 더 많은 오류가 동시에 발생하는데

이 오류는 변수명이 너무 짧고 파리메타의 변수명은 소문자로 시작해야 한다는 것이다.

 board41Ctr, board41Src, boardVO만 수정하고 넘어간다.

다른 파일 코드를 수정하면 오류가 발생하기 때문에 전체적으로 수정해야 한다.

이것은 변수 이름에 대문자가 1개 이상이 사용되었다는 것이다.

Properties > Checkstyle | Configure 에서 "Naming Conventions"에 있는 "Abbreviation As Word In Name"의 체크를 해제해서

명명 규칙 적용을 해제한다.

7. 'X' should be separated from previous statement.가 13회 발생했다.

상세 정보를 보면 'METHOD_DEF' should be separated from previous statement와

',' should be separated from previous statement. 가 있다.

'METHOD_DEF' should be separated from previous statement은 앞 문장과 한 라인을 띄우라는 의미이다.

다음 그림의 27라인에서 엔터키를 치고 저장하면 돋보기가 사라진다.

',' should be separated from previous statement.는 콤마(,) 다음은 다음 라인에서 시작하라는 의미이다.

돋보기에 확인하면 Each variable declaration must be in its own statement라는 문장도 같이 나온다.

Checkstyle violations뷰에 Each variable declaration must be in its own statement는 5회 발생했다.

개인적으로 오류가 난 코드를 선호하여 명명 규칙을 제거할 수도 있는데

위 코드로 수정하였다.

개인적인 코드 작성 원칙이 가급적 많은 코드를 한 화면에서 본다는 것이다.

많은 코드가 한 눈에 보여야 앞뒤 흐름를 파악하여 실제 버그를 빠르고 쉽게 해결한 경험때문이다.

더우기 같은 코드인데 앞뒤 순서에 따라 성능 향상등의 이점을 얻기도 하기 때문이다.

하지만 수정된 코드가 원칙처럼 사용되고 변수 선언 뒤에 //로 해당 변수의 설명을 넣는 것이 좋은 코드 방법이다.

개인적으로는 위 VO의 변수명, 테이블 필드명등의 이름을 동일하게 부여한다.

직관적으로 이해하게 하여 이러한 설명을 빼고 작성한다.

8. 'X' is not preceded with whitespace가 13회 발생했다.

더블 클릭해서 상세화면을 실행한다.

다음 그림과 같이 board41Ctr.java를 찾아서 다시 더블 클릭하면 오류가 발생한 코드를 볼 수 있다.

상세 메세지와 코드로 != 앞뒤로 공백이 없는 것을 확인할 수 있다.

공백을 넣어 주면 오류가 사라진다.

10회 발생한 'X' is not followed by whitespace도 같은 오류라 위 오류 수정에 의해 해제 되기도 한다.

안 될 경우 상세화면에서 해당 코드를 찾아서 공백 처리하면 된다.

아래 코드와 같이 블럭으로 {}를 넣어 주면 된다.

10. Line is longer than X characters (found X) 가 3회 발견되었다.

한 행의 코드 수가 100자를 넘겼다는 의미이다.

다음 그림과 같이 Maximum Line Length를 해제한다.

11. First sentence of Javadoc is incomplete (period is missing) or not present이 3회 발생했다.

이것은 Javadoc에서 언급한 것으로 문장을 마침표(.)로 끝내라는 것이다.

2가지가 더 있지만 모두 앞서 언급한 것과 같이 처리하면 된다.

board41Ctr.java, board41Src.java, boardVO.java의 코드를 보면 돋보기가 모두 사라진 것을 확인 할 수 있다.

board41Src.java에 노랗게 경고 표시가 되어 있는 것이 있다.

이 것은 HashMap의 세부 타일을 표시하면 좋다는 것으로 다음과 같이 수정하면

코드 편집창에 나타난 경고들이 모두 사라진다.

이상으로 명명 규칙등과 관련된 Checkstyle 사용을 살펴 봤다.

이 외에도 더 많은 규칙이 있고 추가도 할 수 있다.

각자에 맞추어 선택하면 될 것이다.

FindBugs는 작성한 프로그램의 잠재적인 결함을 찾아주는 도구이다.

Eclipse 메뉴의 Help > EclipseMarketplace를 실행한 뒤 "findbug"를 검색한다.

다음 그림과 같이 검색된 결과를 설치(install)하면 된다.

설치가 완료되면 Eclipse를 재시작한다.

메뉴에서 Window > Show View > Other를 선택한다.

FindBugs의 Bug Explorer를 선택하고 OK를 선택한다.

Eclipse 하단에 Bug Explorer 뷰가 추가 되어 있는 것을 확인할 수 있다.

프로젝트(board)를 선택하고 마우스 오른쪽 버튼을 눌러 컨텍스트 메뉴를 실행한다.

Find Bugs > Find Bugs를 눌러서 실행한다.

실행 결과 Bug Explorer 뷰에 버그가 없는 것으로 나타난다.

따라서, 다음과 같이 버그를 만들어 실행해 본다.

먼저, board4Ctr의 리스트(board4List) 컨트롤에 다음 색칠된 문장을 추가해 준다.

board4Ctr.java

Find Bugs를 실행하면 다음과 같은 결과가 나오게 된다.

이것은 변수의 값이 Null이라 문제가 생긴다는 의미이다. 

다음과 같이 작성하면 문제를 해결할 수 있다.

if ("a".equals(a)) a = "error";

앞뒤 순서만 바뀐 것 같지만 의미가 다르다.

변수 a 가 Null인데 equals를 사용하면 Null 인데 사용했다고 Null pointer 오류가 발생한다.

Null은 아무 것도 없는 상태로 어떠한 메소드도 사용할 수 없다.

하지만 문자열 "a"에 equals을 사용하면

문자열 "a"는 값이 있는 상태이므로 오류가 발생하지 않는다.

(예제는 변수 값을 Null로 고정한 상태라 Hign confidence에서 Normal confidence로 오류 등급이 떨어진다.)

변수 a는 Null이어도 상관이 없다.

이러한 코드는 컴파일에서는 문제가 없지만

변수의 값에 따라 오류가 발생하기도 하고, 안하기도 하는 귀찮은 문제를 발생시킬 수 있다.