과녁스 이야기

# react directory = /var/www/html
# npm run build
<Directory "/var/www/html">
    ...
    AllowOverride All
    ...
</Directory>

# create .htaccess
Options -MultiViews
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.html [QSA,L]

# or httpd.conf edit
<Directory "/var/www/html">
    #
    # Possible values for the Options directive are "None", "All",
    # or any combination of:
    #   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
    #
    # Note that "MultiViews" must be named *explicitly* --- "Options All"
    # doesn't give it to you.
    #
    # The Options directive is both complicated and important.  Please see
    # http://httpd.apache.org/docs/2.4/mod/core.html#options
    # for more information.
    #
    Options Indexes FollowSymLinks

    #
    # AllowOverride controls what directives may be placed in .htaccess files.
    # It can be "All", "None", or any combination of the keywords:
    #   Options FileInfo AuthConfig Limit
    #
    AllowOverride All

    Options -MultiViews
    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ index.html [QSA,L]

    #
    # Controls who can get stuff from this server.
    #
    Require all granted
</Directory>

리눅스 서버에서 일정 시간마다 서버 간 파일을 동기화해야하는 경우 rsync를 사용하는데 cron을 이용하여 작업을 설정할 경우 비밀번호를 생략할 수 있게 설정이 필요하다

설정방법

A(원본 데이터 존재) 서버와 B(데이터를 복사해올) 서버로 구분

ssh는 개인키와 공개키를 이용하여 인증키 생성 후 요청을 받는 서버(A)에  저장하면 인증이 필요없음

1. B서버 계정 home 디렉토리의 .ssh 디렉토리로 이동
   • .ssh 디렉토리가 없는 경우 외부에서 ssh로 접근하도록 설정 필요
2. ssh-keygen -t rsa
   • -t옵션을 이용하여 파일의 타입을 rsa 형태로 지정
3. 생성된 rsa의 파일(id_rsa.pub) 파일의 내용을 복사
4. A서버의 계정이 홈 디렉토리의 .ssh 디렉토리로 이동
5. A서버에 복사해온 id_rsa.pub의 내용을 authorized_keys 파일을 편집하여 추가
   • 파일이 없는 경우 새로 추가
6. B서버에서 실행
   
   1. rsync -avz A서버주소:/home/test/data /home/bserver/test/data

명령 프롬프트

1. 관리자 권한으로 cmd 실행
2. sc delete [서비스명]

레지스터

1. regedit 실행
2. HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services에서 원하는 서비스 삭제

내용

외부에 제공되는 사이트 중 TLSv1.2로 업그레이드가 필요한 경우가 있어서 조사하던 중 Windows 버전에 따라서 IE의 TLSv1.2가 default로 설정되어 있는지 확인이 필요하여 알아보았다.

IE11에서는 기본으로 TLSv1.2가 설정되어 있지만, 윈도우8 이하에서는 IE버전이 11보다 낮으면 기본으로 설정되어 있지 않았다.

TLS 확인

openssl이 설치되어있어야함

openssl s_client -connect www.test.com:8088  -tls1_2

내용

1. 운영중인 서비스 디스크 사용량이 100%로 확인되어 각 디렉토리 별 용량을 확인하여 로그파일을 삭제
2. 로그파일을 삭제하였으나, df로 확인해본결과 사용량이 그대로 100%여서 파일 쓰기가 정상적으로 실행되지 않음

조치사항

1. 확인해본결과 해당 로그를 사용중인 프로세스가 파일을 닫지 못하여서 용량을 차지
   • lsof -nP | grep deleted 명령어로 실행중인 프로세스 확인
2. 프로세스 확인 후 프로세스 kill
   • kill -9 (PID)

root권한 획득 후

curl -sL https://rpm.nodesource.com/setup_12.x | bash -

npm init -y

npm install babel-cli@6 babel-preset-react-app@3

OWASP에 대하여

Open Web Application Security Project(OWASP)는 조직에서 신뢰할 수 있는 애플리케이션과 API를 개발, 구매, 유지 관리할 수 있도록 지원하는 열린 커뮤니티입니다.

A1:2017- 인젝션

SQL, OS, XXE, LDAP 인젝션 취약점은 신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부분으로써, 인터프리터로 보내질 때 발생합니다. 공격자의 악의적인 데이터는 예기치 않은 명령을 실행하거나 올바른 권한 없이 데이터에 접근하도록 인터프리터를 속일 수 있습니다.

A2:2017- 취약한 인증

인증 및 세션 관리와 관련된 애플리케이션 기능이 종종 잘못 구현되어 공격자들이 암호, 키, 세션 토큰을 위험에 노출시킬 수 있거나 일시적 또는 영구적으로 다른 사용자의 권한 획득을 위해 구현 상 결함을 악용하도록 허용합니다. 

A3:2017- 민감한 데이터 노출

다수의 웹 애플리케이션과 API는 금융 정보, 건강 정보, 개인 식별 정보와 같은 중요한 정보를 제대로 보호하지 않습니다. 공격자는 신용카드 사기, 신분 도용 또는 다른 범죄를 수행하기 위해 보호가 취약한 데이터를 훔치거나 수정할 수 있습니다. 중요한 데이터는 저장 또는 전송할 때 암호화 같은 추가 보호 조치가 없으면 탈취 당할 수 있으며, 브라우저에서 주고 받을 때 각별한 주의가 필요합니다. 

A4:2017- XML 외부 개체 (XXE)

오래되고 설정이 엉망인 많은 XML 프로세서들은 XML 문서 내에서 외부 개체 참조를 평가합니다. 외부 개체는 파일 URI 처리기, 내부 파일 공유, 내부 포트 스캔, 원격 코드 실행과 서비스 거부 공격을 사용하여 내부 파일을 공개하는데 사용할 수 있습니다.

A5:2017- 취약한 접근 통제

인증된 사용자가 수행할 수 있는 작업에 대한 제한이 제대로 적용되어 있지 않습니다. 공격자는 이러한 결함을 악용하여 다른 사용자의 계정에 접근하거나, 중요한 파일을 보거나, 다른 사용자의 데이터를 수정하거나, 접근 권한을 변경하는 등 권한 없는 기능과 데이터에 접근할 수 있습니다. 

A6:2017- 잘못된 보안 구성

잘못된 보안 구성은 가장 흔하게 보이는 이슈입니다. 취약한 기본 설정, 미완성 (또는 임시 설정), 개방된 클라우드 스토리지, 잘못 구성된 HTTP 헤더 및 민감한 정보가 포함된 장황한 에러 메시지로 인한 결과입니다. 모든 운영체제, 프레임워크, 라이브러리와 애플리케이션을 안전하게 설정해야 할 뿐만 아니라 시기 적절하게 패치/ 업그레이드를 진행해야 합니다.

A7:2017- 크로스 사이트 스크립팅 (XSS)

XSS 취약점은 애플리케이션이 올바른 유효성 검사 또는 필터링 처리 없이 새 웹 페이지에 신뢰할 수 없는 데이터를 포함하거나, 자바스크립트와 HTML을 생성하는 브라우저 API를 활용한 사용자 제공 데이터로 기존 웹 페이지를 업데이트할 때 발생합니다. XSS는 피해자의 브라우저에서 공격자에 의해 스크립트를 실행시켜 사용자 세션을 탈취할 수 있게 만들고, 웹 사이트를 변조시키고, 악성 사이트로 리다이렉션할 수 있도록 허용합니다

A8:2017- 안전하지 않은 역직렬화

안전하지 않은 역직렬화는 종종 원격 코드 실행으로 이어집니다. 역직렬화 취약점이 원격 코드 실행 결과를 가져오지 않더라도 이는 권한 상승 공격, 주입 공격과 재생 공격을 포함한 다양한 공격 수행에 사용될 수 있습니다.

A9:2017- 알려진 취약점이 있는 구성요소 사용

라이브러리, 프레임워크 및 다른 소프트웨어 모듈 같은 컴포넌트는 애플리케이션과 같은 권한으로 실행됩니다. 만약에 취약한 컴포넌트가 악용된 경우, 이는 심각한 데이터 손실을 일으키거나 서버가 장악됩니다. 알려진 취약점이 있는 컴포넌트를 사용한 애플리케이션과 API는 애플리케이션 방어를 약화시키거나 다양한 공격과 영향을 주게 합니다.

 A10:2017- 불충분한 로깅 & 모니터링

불충분한 로깅과 모니터링은 사고 대응의 비효율적인 통합 또는 누락과 함께 공격자들이 시스템을 더 공격하고, 지속성을 유지하며, 더 많은 시스템을 중심으로 공격할 수 있도록 만들고, 데이터를 변조, 추출 또는 파괴할 수 있습니다. 대부분의 침해 사례에서 침해를 탐지하는 시간이 200일이 넘게 걸리는 것을 보여주고, 이는 일반적으로 내부 프로세스와 모니터링보다 외부 기관이 탐지합니다

디자인 패턴(Design Pattern) 이란?

“소프트웨어 디자인 패턴이란 소프트웨어 디자인에서 계속 재현되는 문제를 해결하는 재사용 가능한 해결법이다.”(A software design pattern is a reusable solution to a reoccurring software design pattern. 출처 Programming in the Large with Design Patterns. Eddie Burris)
상기 출처의 저서에서의 설명처럼 디자인패턴이랑 소프트웨어 개발간 또는 디자인간에 재현되는 문제를 해결할 수 있고 매 문제 발생시마다 그 재사용 할 수 있는 해결방법이라고 생각합니다.

예를들어 소프트웨어 개발간에서 모든 “특정 클래스가 실행간에 단 한번만 인스턴스화 되어 객체로 이용가능하여야 한다.” 라는 문제를 해결하기 위해 “싱글톤 디자인패턴(Singleton Design Pattern)”을 이용해볼 수 있습니다. 또는 특정 클래스의 생성 또는 객체화에 있어 호출당시의 콘텍스트(Context)를 고려하여 클래스를 반환해주는 “팩토리 디자인패턴(Factory Design Pattern)”이 유용하게 사용해볼 수 있습니다.
이렇듯, 디자인 패턴은 소프트웨어의 디자인(설계)간에 발생하는 문제를 해결해주는 해법이라고 볼수 있습니다. 단, 디자인 패턴은 데이터 구조 또는 알고리즘과 다르며, 아주 특정한 구조에서 특정한 문제에 한하여 한번만 문제를 해결할수 있는 디자인은 “디자인 패턴”이라고 보기는 어렵다는 견해도 있습니다.(조금 더 설명하자면, 디자인 패턴은 유사한 문제에 대해 특정 패턴들을 재사용하여 문제를 해결하는 소프트웨어 개발 방법론이라고 생각하는데, 재사용이 가능하지 않거나 아주 구체적인 특정 문제에서만 몇번 이용할 수 있는 디자인은 패턴으로 보기 어려울 수 있습니다.)

조금 더 쉽게 말해 디자인 패턴(Design Pattern)은  문제/의도/해결방법이 명시적입니다. 즉 해당 패턴이 사용되는 문제가 “정형화” 되어 있으며, 해당 문제를 접근하는데 어떠한 의도를 가지고 어떻게 해결하는지에 대해서 명시적인 해결 방법 또는 접근 방법을 제안합니다.

• Decorator
• Facade
• Observer
• Singleton
• Factory
• Strategy
• Proxy
• Adapter
• Iterator
• State

위 나열한 각 디자인 패턴의 명칭 처럼 정형화된 문제에서 해당 문제에 접근하는 의도와 해결법도 패턴으로 정형화 되어 있습니다. 디자인 패턴에 대한 목록은 (https://en.wikipedia.org/wiki/Software_design_pattern) 에서 더 확인해볼 수 있습니다. 위의 각 패턴들 중에서는 저 자신도 몇가지는 아직 프로젝트에서 응용해 보지 못한 패턴들도 많습니다. 그래서 각 패턴에 대한 설명보다도 디자인 패턴에 대한 공부와 소프트웨어 개발 프로젝트에서의 응용을 통해서 어떠한 효과를 체감 할 수 있었는지에 대해서 정리하고 글을 마치도록 하겠습니다.

1. 재현되는 디자인 문제에 대해서 프로젝트간 또는 팀 내부에서 공유하는 공통의 해법 도출

데이터 구조(Data Structure) 또는 특정 알고리즘을 해결가능한 범위가 아닌 디자인에서 기인하는 문제를 해결하기 위해 차용 하는 해결방법이 프로젝트 범위 또는 협업하는 팀 내부 개발자간에 공통된 원칙을 고수 할수 있게 되었습니다. 이에 따라 공통된 원칙하게 개발되어 코드의 구조가 팀 내부에서 더 잘 리뷰되어 공유될수 있었으며, 해결방법도 기존에 각 개발자마다 자의적으로 선택하던 방식에서 팀내에 수립된 원칙에서 권장되는 해법으로 통일될 수 있었습니다.

2.각 디자인 패턴의 문제/의도/해결방법을 학습함에 따라 소프트웨어 설계에 맞닥뜨리는 문제에 대한 빠른 유형 파악 및 해결방법 제안

앞서 설명한 것처럼 디자인 패턴은 항상 그 패턴이 사용되는 문제의 상황과 문제를 풀어가고자 하는 의도/방안이 명시적입니다. 그래서 여러 패턴을 조금씩 공부하다 보니, 소프트웨어 설계시 발생하는 디자인 문제에 대해 정형화 하여 빠른 해법을 도출할 수 있다는 장점이 있었습니다.

3.디자인 패턴의 재사용이 곧 코드의 재사용으로 이어져 이전보다 상대적으로 빠른 개발속도 및 유지보수에 용이

패턴을 사용한다고 코드의 재사용이 꼭 발생한다고 보장할수는 없지만, 제 체감으로는 패턴을 통해 구현된 클래스 유연함(Flexibililty)이 적지 않게 코드의 재사용으로 이어지는 결과를 보게 됩니다. 이에 따라 코드의 구조화와 재사용으로 생산성이 올라가고, 팀 내부의 문제를 해결하는 방법에 대한 협의된 원칙으로 코드의 개선/유지보수에서도 가독성이 높아져 더 빠른 생산성을 기대해 볼수 있었습니다.

• GET은 주소줄에 값이 ?뒤에 쌍으로 이어붙고 POST는 request정보의 body안에 값으로 보내진다.

• GET은 URL에 이어붙기 때문에 길이제한이 있어서 많은양의 데이터는 보내기 어렵고 POST는 많은 양의 보내기에도 적합하다.(역시 용량제한은 있지만)
  

• http://www.xxx.com/list.html?id=5&pagenum=2 같이 하는 것이 GET방식이고 form을 이용해서 submit을 하는 형태가 POST입니다.

REST 탄생

REST는 Representational State Transfer라는 용어의 약자로서 2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개되었습니다. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다고 합니다.

REST 정의

HTTP URL로 잘 표현된 리소스를 HTTP Method로 정의하여 리소스의 내용 (xml, json 등)으로 표현하는 것.

URI(Uniform Resource Identifier)으로 통합 자원 식별자라는 의미로 특정 자원의 위치를 나태내는 유일한 주소로 대표적으로 URL(Uniform Resource Locator)가 URI에 포함된다.

REST 특징

1. Uniform(유니폼 인터페이스) : 정해진 URI 리소스에 대해서 조작을 통일되고 정형화된 인터페이스로 수행하는 아키텍쳐 스타일

2. Statesless(무상태성) : REST는 상태정보를 별도로 저장하지 않고 관리도 하지 않는다. 세션이나 쿠키정보를 저장하지 않기 때문에 API에 들어오는 요청만 단순처리하면 된다.

3. Cacheable(캐시 가능) : 기존 HTTP 웹 표준을 그대로 사용하기때문에 HTTP의 캐싱 기능 적용 가능. Last-Modified태그나 E-Tag를 이용하여 캐싱 구현 가능

4. Self-Descriptivness(자체 표현 구저) : REST에 표현만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어있다.

5. Client-Server 구조 : 클라이언트는 사용자 인증이나 컨텍스트(세션, 쿠키 등)을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명학해지고 서로의 대한 의존성이 줄어든다.

6. 계층형 구조 : REST서버는 다중 계층으로 구성할 수 있고 이에 대해서 클라이언트는 알 수 없다. 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상에 유연성을 줄 수 있고 Proxy, 게이트웨어 같은 네트워크 기반의 중간매체를 사용할 수 있다.