프로그래밍 언어 응용(2)

1. 코드 인스펙션

(1) 인스펙션 수행 절차

• 중재자, 저자, 진행자, 검토자, 기록자 등의 역할 담당자를 지정하여 진행한다.
• 개발 초기 단계에서 결함을 식별하여 수정함으로
• 오류로 인한 비용 최소화 / 코드 품질 향상 / 유사 결함 발생 예방 및 유지보수 효율성 향상
• 을 목적으로 진행한다. 

단계	수행 내용
계획(Planning)	- 인스펙션 대상 산출물 선정 및 대상자를 구성  - 인스펙션 대상 산출물 사전 배포 및 날짜, 시간, 장소 공지
개관(Overview)	- 참여자 대상 산출물에 대한 이해도 높여 인스펙션의 효과성 향상시킬 수 있음  - 생략 가능
준비 (Preparation)	- 구성원이 개별적으로 산출물에 대해 숙지하고 체크리스트를 활용하여 결함부분에 대해 기록
검토회의 (Meeting)	- 산출물을 함께 검토하며 준비단계나 검토회의에서 식별된 결함 부분에 대해 집중
재작업(Rework)	- 검토회의에서 발견된 결함 수정
추적(Follow-up)	- 결함이 정상적으로 수정되었는지 최종 확인 후 인스펙션 종료

 

(2) 코드리뷰 기법 비교

• 프로젝트 상황 및 코드의 중요도에 따라 기법 선택 및 적용
• 동료검토 / 워크스루 / 테크니컬 리뷰 / 인스펙션

단계	수행 내용
동료검토 (Peer Review)	- 별도 절차 없이 비공식으로 계획 없이 임의 실시 된다.  - 개발자가 동료와 코드 및 산출물의 결함을 식별하는 기법
워크스루 (Walk Through)	- 개발자가 리뷰의 주제와 시간을 정해서 발표 진행  - 발표 후 동료들로부터 의견이나 아이디어를 듣는 시간을 가짐  - 사례에 대한 정보 공유나 아이디어 수집을 위해 사용될 수 있음
인스펙션(Inspction)	- 역할과 절차, 체크리스트를 기준으로 결함을 식별하는 공식 리뷰 기법

 

2. 리팩토링(Refactoring)

SW의 원래 기능은 유지하면서 소스코드의 내부 구조를 수정 및 보완하여 
가독성, 성능향상 및 로직을 개선하는 방법이다.

(1) 주요 리팩토링 대상 및 방법

대상	방법
중복된 코드 (Duplicated Code)	- 중복 제거
긴 메소드 (Long Method)	- 메소드를 적정 수준의 크기로 나누기
긴 파라미터 리스트 (Long Parameter List)	- 파라미터 개수 줄이기
게으른 클래스 (Lazy Class)	- 자식 클래스와 부모 클래스의 차이가 없으면 합치기
주석(Comment)	- 주석이 없어도 코드를 이해할 수 있도록 소스코드 변경
메시지 체인(Message Chain)	- 특정 객체를 얻기 위한 다수 객체는 간소화
미들 맨 (Middle Man)	- 다른 클래스로 위임하는 역할만 담당하는 클래스 제거 검토
불완전 라이브러리 (Incomplete Library)	- 불완전 시 필요 부분 추가 구성
스위치 명령문 (Switch Statements)	- 지나치게 많은 case를 사용하는 Switch 문장은 코드 중복의 신호이다.

 

(2) 리팩토링 수행 절차

출처: https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=yulian&logNo=10177348055

 

3. OWASP TOP 10

OWASP(The Open Web Application Security Project)
웹 어플리케이션에 대한 보안 프로젝트

OWASP TOP 10
웹 어플리케이션 취약점 중 빈도가 많이 발생하고 보안상 영향을 크게 줄 수 있는 10가지

출처: https://owasp.org/www-project-top-ten/ 

항목	내용
접근 권한 취약점 (Broken Access Control)	- 타인의 계정 접근 / 중요 데이터 열람 및 수정 / 엑세스 권한 변경 등  - 악의적인 행위가 가능한 취약점
암호화 오류 (Cryptographic Failures)	- 민감 데이터 노출 명칭의 변경  - 적절한 암호화가 이루어지지 않으면 민감 데이터가 노출될 수 있음
Injection	- 웹 어플리케이션에 비정상적인 명령어나 쿼리 등을 보내  - 공격자가 시스템에 불법적으로 접근할 수 있는 취약점
Insecure Design	- 안전하지 않은 설계는 누락되거나 비효율적인 제어 설계로 표현되는 다양한 취약점  - 안전하지 않은 설계에서 취약점으로 이어지는 구현 결함 있을 수 있음
Security Misconfiguration	- 안전하지 않은 구성, 잘못된 구성으로  - HTTP Header나 민감 정보가 포함된 에러 메시지 등으로 인한 취약점
Vulnerable & Outdated Components	- 취약하고 오래된 요소  - 지원이 종료되었거나 오래된 버전을 사용할 때 발생
식별 및 인증 오류 (Identification & Authentication Failures)	- 취약한 인증 + 식별 실패 --> 더 넓은 범위를 포함하게 변경되었다.  - 사용자의 신원확인 / 인증 및 세션관리가 적절히 되지 않을 때 취약점 발생 가능
무결성 오류 (SW & Data Integrity Failures)	- 2021년 새롭게 등장한 카테고리  - 무결성 확인하지 않고 SW 업데이트 / 중요 데이터 및 CI/CD 파이프라인과 관련된 가정에 중점
보안 로깅 및 모니터링 실패 (Security Logging & Monitoring Failures)	- 불충분한 로깅 및 모니터링 --> 보안 로깅 및 모니터링 실패로 변경  - 진행중인 공격을 감지 및 대응하는 데 도움이 됨
서버 측 요청 위조 [Server-Side Request Foregery (SSRF)]	- 2021년 새롭게 등장한 카테고리  - 웹 어플리케이션이 유저가 제공한 URL의 유효성을 검사하지 않고 원격 리소스 가져올 때 발생

 

3. 정적 분석과 PMD

(1) 정적 분석(Static Analysis)

• 동적 분석(Dynamic Analysis)과 상대되는 개념
• SW를 실행하지 않고 코드 레벨에서 분석하는 방법
• 소스코드의 실행 없이 코드의 의미를 분석해 결함을 찾아내는 코드 분석 기법
• 오류가 존재하는 부분을 사전에 식별해 영향 범위 최소화 가능
• 테스팅 단계에서의 부담을 줄여 프로그램의 품질 높일 수 있음

 

(2) PMD(Progrmming Mistake Detector)

• 응용 프로그램 코드의 문제를 사전에 확인할 수 있는 정적 분석을 위한 오픈 소스코드 분석 도구
• 기본 제공 규칙 세트가 포함되어 있고 사용자 지정 규칙 작성 가능
• 단독 형태로도 사용할 수 있고 이클립스 등과 같은 IDE에 플러그인 형태로 배포되어 누구나 사용 가능하다

---

1. 토이메이커스 / 소프트웨어공학

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=yulian&logNo=10177348055 

리팩토링(Refactoring)

 

2. OWASP TOP 10

https://owasp.org/www-project-top-ten/

OWASP Top Ten Web Application Security Risks | OWASP