고니의꿈

1. 브로큰 액세스 컨트롤

2017년 5위에서 2021년에 목록의 상단으로 올라온 브로큰 액세스 컨트롤은 지속적이고 중대한 위협으로 남아 있습니다. 액세스 컨트롤은 사용자가 사용할 수 있는 리소스와 기능을 제한하며, 시스템이 적절한 제한을 시행하지 못할 때 사용되는 용어입니다.

이는 잘못된 구성, IDOR(안전하지 않은 직접 객체 참조) 등 여러 가지 이유로 발생할 수 있습니다. IDOR은 애플리케이션이 파일이나 데이터베이스 레코드 같은 리소스에 대한 직접 참조를 노출하는 경우입니다. 또한, 세션 관리의 취약점으로 인해 공격자가 사용자의 세션을 가로채는 것과 같은 문제가 발생할 수 있습니다.

개발자와 시스템 관리자는 여기서 최소 권한 원칙을 따라야 합니다. 이는 사용자에게 그들의 업무 수행에 필요한 최소한의 권한만 부여하고 그 이상은 부여하지 않는 것을 의미합니다.

모든 사용자 입력은 악의적인 데이터를 주입하는 공격자를 방지하기 위해 검증되고 정화되어야 하며, API에 액세스 컨트롤이 적용되고 모든 요청에 대한 권한이 확인되어야 합니다.

정기적인 보안 감사와 코드 리뷰는 액세스 컨트롤 문제를 식별하고 해결하는 데 필수적이며, 무단 접근을 제한하기 위해 다중 인증이 강제되어야 합니다.

2. 암호화 실패

이 문제는 이전에 '민감한 데이터 노출'이라고 불리며 3위에 올랐었지만, 이전 이름이 원인보다 증상을 묘사했기 때문에 이름이 변경되었습니다. 암호화는 신용카드 번호와 개인 식별 정보(PII) 같은 매우 민감한 데이터를 전송 중에 보호하는 데 사용되지만, 약한 암호화 알고리즘이나 짧은 암호화 키와 같은 요인들로 인해 실패할 수 있습니다. 이는 공격자가 민감한 데이터를 더 쉽게 해독할 수 있게 만듭니다.

암호화 실패의 다른 예로는 불안전한 비밀번호 저장, 충분하지 않은 전송 계층 보안(중간자 공격으로 이어질 수 있음), 약한 SSL/TLS 프로토콜, 그리고 웹 애플리케이션을 공격에 노출시킬 수 있는 불안전한 암호 스위트가 있습니다.

정기적인 보안 테스트(코드 리뷰 및 취약점 평가 포함)를 실시하여 암호화 취약점을 식별하고 해결하며, 또한 안전한 암호화 라이브러리 사용도 고려하세요.

3. 인젝션

인젝션은 2017년에 1위를 차지했고, 크로스 사이트 스크립팅은 7위였습니다. 이제 이들은 OWASP 2023의 현재 3위를 차지하는 하나의 우산 용어 아래 통합되었습니다.

인젝션 공격은 입력 유효성 검사의 취약점과 불충분한 데이터 처리를 이용합니다. 공격자들은 SQL 쿼리, 코드 스니펫, 명령어 등의 데이터를 웹 애플리케이션 폼이나 URL에 삽입합니다. 이를 통해 적들이 민감한 데이터에 접근하고 애플리케이션의 동작을 조작할 수 있습니다.

인젝션의 예시는 다음과 같습니다:

-       SQL 인젝션: 데이터베이스 공격을 위한 것입니다.

-       크로스 사이트 스크립팅(XSS): 주로 자바스크립트 기반의 브라우저 공격으로, 감염된 웹 페이지를 통해 실행되며 세션 탈취, 쿠키 도난 또는 사용자에 대한 기타 공격으로 이어질 수 있습니다.

-       커맨드 인젝션: 공격자가 애플리케이션이 실행하는 시스템 명령어에 악의적인 명령어를 삽입하여 서버를 제어하거나 허가되지 않은 작업을 수행할 수 있습니다.

-       LDAP 인젝션: 공격자가 인증 및 권한 부여에 사용되는 LDAP 쿼리를 조작하여 접근 권한을 얻습니다.

-       XML 인젝션: 공격자가 XML 데이터에 악의적인 내용을 삽입하여 애플리케이션의 파싱 과정을 방해하거나 접근 권한을 얻습니다.

-       서버 측 템플릿 인젝션(SSTI): 공격자가 서버 측 템플릿에 악의적인 코드를 삽입하여 서버에서 코드를 실행합니다.

4. 불안전한 디자인

이 OWASP 2023 범주는 2021년에 새로 생겼으며, 해커들이 이용할 수 있는 잘못된 애플리케이션 설계와 아키텍처의 결함을 다룹니다. 불안전한 디자인 취약점은 팀이 보안 모범 사례를 준수하지 않고 애플리케이션을 만드는 코드 설계 단계에서 잠재적 위협을 충분히 예측하고 평가하지 못할 때 발생합니다.

불안전한 디자인의 예는 지나치게 상세한 오류 메시지를 생성하는 앱입니다. 오류 상황에 대해 너무 자세한 정보를 제공하고 애플리케이션 환경이나 기타 관련 데이터에 대한 진단적 힌트를 제공한다면, 공격자에게 유용한 정보를 제공할 수 있습니다. 이 정보를 사용하여 경로 탐색이나 SQL 인젝션과 같은 다른 공격을 시작할 수 있습니다.

일관된 위협 모델링을 사용하여 알려진 공격 방법을 차단함으로써 디자인 취약점을 완화하는 것이 중요합니다.

5. 보안 미설정

이 범주는 이제 2017년의 XML 외부 엔티티(XXE) 범주를 포함합니다. 보안 미설정은 다양한 잠재적 취약점을 포함하지만, 가장 흔한 것들은 다음과 같습니다:

·       패치되지 않은 취약점

·       기본 설정

·       사용되지 않는 페이지

·       보호되지 않은 파일 및 디렉토리

·       불필요한 서비스

·       취약한 XML 파일 사용

웹마스터들이 자주 저지르는 실수 중 하나는 CMS(콘텐츠 관리 시스템) 기본 설정을 변경하지 않는 것입니다. CMS 애플리케이션은 사용자 친화적이지만, 최종 사용자에게 보안 위험을 초래할 수 있습니다. 많은 공격은 전적으로 자동화되어 있으며 기본 설정을 이용한 공격에 의존하므로, CMS 설치 시 이러한 설정을 변경하는 것이 잠재적 공격을 상당 부분 완화하는 데 중요합니다.

댓글 관리, 사용자 접근 제어, 사용자 정보 가시성 및 기본 파일 권한 설정을 조정하여 보안을 강화할 수 있습니다.

6. 취약하고 구식인 구성요소

가장 단순한 웹사이트조차 프레임워크, 라이브러리, 확장 프로그램, 플러그인 등 많은 의존성을 가지고 있으며, 이 모든 것은 최신 상태로 유지되어야 합니다. 공격자들은 취약한 구성요소를 가진 웹사이트를 찾아 멀웨어를 퍼뜨리거나 피싱 공격을 시작하는 등의 이용을 시도하므로, 어떤 이유로든 업데이트를 설치하지 않는 것은 좋지 않은 생각입니다.

어떤 소프트웨어의 최신 버전은 최신 보안 업데이트를 포함할 것이지만, 웹사이트가 많은 의존성에 의존하는 경우 이는 쉽게 말할 수 있지만 행하기 어렵습니다. 이를 해결하기 위한 첫 번째 단계는 환경에 연결된 모든 구성요소를 나열하고 각각의 동작을 최신 상태로 유지하는 목록을 생성하는 것입니다. Reflectiz와 같은 도구가 자동으로 이를 수행할 수 있습니다.

7. 식별 및 인증 실패

인증 및 신원 관리 실패는 애플리케이션을 악의적인 행위자가 정당한 사용자로 위장하는 위험에 노출시킵니다. 유효 기간 없이 구성된 세션 ID는 계속 실행될 수 있습니다. 약한 비밀번호는 추측에 취약할 수 있으며, 로그인 시도에 대한 제한이 없으면 자동화된 공격이 성공할 때까지 계속됩니다.

이러한 문제를 해결하기 위해 애플리케이션 내에서 다중 인증 요소(MFA)를 구현합니다. 또한, 개발자들은 권장되는 비밀번호 길이, 복잡성 및 회전 정책을 준수해야 할 필요성을 인식해야 합니다.

8. 소프트웨어 및 데이터 무결성 실패

이것들은 설계 결함의 일종입니다. 현대 아키텍처의 복잡성으로 인해 개발자들은 종종 다양한 출처에서 플러그인과 라이브러리를 파이프라인에 추가하고 그들의 무결성을 확인하지 않습니다. 이들 중 하나라도 실패하면 애플리케이션이 무단 정보 공개, 시스템 손상 또는 악의적 코드 삽입에 취약해질 수 있습니다. 이것이 제3자 및 오픈 소스 플러그인과 라이브러리의 활성 목록을 유지하고 지속적인 위협 모니터링을 수행하는 것이 중요한 이유입니다.

9. 보안 로깅 및 모니터링 실패

불량한 로깅 및 모니터링 기능은 사고가 누락되고 경고가 생성되지 않으며, 상당한 피해를 입힐 만큼 충분히 오랫동안 눈에 띄지 않을 수 있습니다.

로그인 시도 및 실패는 로그되어야 하며, 서버 장애 시를 대비하여 로그의 백업이 필요합니다. 로그는 모니터링 시스템이 의심스

러운 활동을 감지하거나 적시에 경고를 발생시킬 수 있도록 정확해야 하며, 또한 변조로부터 보호되어야 합니다.

취약점을 완화하기 위해 모든 로그인 시도(실패 포함)를 기록하고, 로그의 사본을 유지하며, 반탐퍼 메커니즘을 사용하고, 정기적으로 모니터링 시스템을 테스트하세요.

10. 서버 측 요청 위조(SSRF)

이 취약점은 공격자가 서버를 통해 다른 내부 또는 외부 리소스에 대한 무단 요청을 할 수 있게 합니다. SSRF 공격에서 공격자는 입력 필드나 애플리케이션의 파라미터를 조작하여 서버가 임의의 URL로 요청을 보내게 할 수 있으며, 이는 종종 사용자가 알지 못하는 상태에서 발생합니다.

공격자는 이 취약점을 악용하여 민감한 데이터에 접근하거나 내부 리소스와 상호 작용하거나 서버를 대신하여 행동을 수행할 수 있으며, 이는 애플리케이션이나 그 인프라의 완전한 손상으로 이어질 수 있습니다.

SSRF 취약점을 완화하기 위해 개발자들은 다음과 같은 모범 사례를 따라야 합니다:

입력 검증: 요청에 악의적인 URL이나 IP 주소가 사용되는 것을 방지하기 위해 사용자 제공 입력을 적절히 검증하고 정화합니다.

화이트리스팅: 허용된 URL 또는 IP 범위에 대한 화이트리스팅을 구현하여 서버가 알려진 안전한 리소스로 요청을 제한합니다.

방화벽 규칙: 서버로부터 특정 리소스와 프로토콜로의 나가는 요청을 제한하기 위해 방화벽 및 네트워크 설정을 구성합니다.

안전한 API 사용: 애플리케이션이 외부 리소스에 요청을 해야 하는 경우, 안전한 API 또는 공개 접근을 위해 의도된 특정 엔드포인트를 사용합니다.

최소 권한: SSRF 공격이 발생할 경우 잠재적 피해를 제한하기 위해 서버가 외부 리소스에 접근할 수 있는 최소 권한을 갖도록 합니다.

2023년 OWASP Top 10 API 보안 위험 목록은 API 보안에 있어 가장 중요한 위험들을 강조합니다. 각 항목의 설명은 다음과 같습니다:

1. API1:2023 - 부적절한 객체 수준 권한 부여 (Broken Object Level Authorization):

   • API는 객체 식별자를 다루는 엔드포인트를 노출하는 경향이 있으며, 이로 인해 객체 수준 접근 제어 문제가 발생합니다. 사용자로부터 ID를 사용하여 데이터 소스에 접근하는 모든 함수에서 객체 수준 권한 부여 검사를 고려해야 합니다.

2. API2:2023 - 부적절한 인증 (Broken Authentication):

   • 인증 메커니즘은 종종 잘못 구현되어, 공격자가 인증 토큰을 탈취하거나 다른 사용자의 신원을 일시적 또는 영구적으로 가정하는 구현상의 결함을 악용할 수 있습니다. 시스템이 클라이언트/사용자를 식별하는 능력을 손상시키면 API 보안 전반에 영향을 줍니다.

3. API3:2023 - 부적절한 객체 속성 수준 권한 부여 (Broken Object Property Level Authorization):

   • 이 카테고리는 API3:2019 과도한 데이터 노출과 API6:2019 대량 할당을 결합하며, 객체 속성 수준에서 부적절하거나 부재하는 권한 검증이 근본 원인입니다. 이로 인해 무단 당사자에 의한 정보 노출 또는 조작이 발생할 수 있습니다.

4. API4:2023 - 무제한 자원 소비 (Unrestricted Resource Consumption):

   • API 요청을 처리하기 위해서는 네트워크 대역폭, CPU, 메모리 및 저장소와 같은 자원이 필요합니다. 이메일/SMS/전화 통화 또는 생체 인증 검증과 같은 다른 자원은 서비스 제공업체를 통해 API 통합을 통해 사용 가능하며 요청당 비용이 청구됩니다. 성공적인 공격은 서비스 거부 또는 운영 비용 증가로 이어질 수 있습니다.

5. API5:2023 - 부적절한 기능 수준 권한 부여 (Broken Function Level Authorization):

   • 다양한 계층, 그룹 및 역할을 가진 복잡한 접근 제어 정책과 관리적 기능과 일반 기능 간 명확하지 않은 구분은 권한 부여 결함으로 이어질 수 있습니다. 이러한 문제를 악용함으로써 공격자는 다른 사용자의 자원 및/또는 관리 기능에 접근할 수 있습니다.

6. API6:2023 - 민감한 비즈니스 흐름에 대한 무제한 접근 (Unrestricted Access to Sensitive Business Flows):

   • 이 위험에 취약한 API는 티켓 구매 또는 댓글 게시와 같은 비즈니스 흐름을 노출하지만, 자동화된 방식으로 과도하게 사용될 경우 비즈니스에 해를 끼칠 수 있는 기능에 대한 보상을 고려하지 않습니다. 이는 반드시 구현 버그에서 나오는 것은 아닙니다.

7. API7:2023 - 서버 측 요청 위조 (Server Side Request Forgery):

   • 사용자 제공 URI를 검증하지 않고 API가 원격 리소스를 가져올 때 서버 측 요청 위조(SSRF) 결함이 발생할 수 있습니다. 이를 통해 공격자는 애플리케이션을 속여 방화벽이나 VPN으로 보호되는 예기치 않은 목적지로 조작된 요청을 보낼 수 있습니다.

8. API8:2023 - 보안 설정 오류 (Security Misconfiguration):

   • API와 이를 지원하는 시스템은 일반적으로 복잡한 구성을 포함하며, 이는 API를 더 맞춤화할 수 있게 합니다. 소프트웨어 및 DevOps 엔지니어는 이러한 구성을 놓치거나 구성과 관련된 보안 모범 사례를 따르지 않을 수 있으며, 이는 다양한 유형의 공격에 문을 열 수 있습니다.

9. API9:2023 - 부적절한 재고 관리 (Improper Inventory Management):

   • API는 전통적인 웹 애플리케이션보다 더 많은 엔드포인트를 노출하는 경향이 있어, 적절하고 최신의 문서 작성이 매우 중요합니다. 호스트 및 배포된 API 버전의 적절한 재고도 중요하며, 이는 폐기된 API 버전 및 노출된 디버그 엔드포인트와 같은 문제를 완화하는 데 도움이 됩니다.

10. API10:2023 - API의 안전하지 않은 사용 (Unsafe Consumption of APIs):

    • 개발자는 사용자 입력보다 제3자 API에서 받은 데이터를 더 신뢰하는 경향이 있으며, 따라서 보안 표준을 약화시키는 경향이 있습니다. API를 손상시키기 위해 공격자는 대상 API를 직접 공격하기보다는 통합된 제3자 서비스를 공격합니다.

1. 채널에서 마우스 오른쪽 버튼 - 채널 세부정보 보기

2. 통합 탭 선택 후 "앱 추가" 클릭

3. webhoock 으로 검색해서 "Incoming WebHooks" 설치.

4. "Slack에 추가" 클릭

5. 채널 선택 수 "수신 웹후크 통합 앱 추가" 클릭

6. 웹후크 URL 획득

7. 메시지 전송 방법

8.  링크 추가, 사용자 지정된 모양, 채널 재정의 

9. 전문 예시

IE에서 "교차 사이트 스크립팅을 방하기 위해 Internet Explorer가 이 페이지를 변경했습니다." 라는 메시지가 뜨면서 사이트에 # (샵) 표시 하나만 덩그러니 뜨는 현상을 마주하고 많이 당황스러웠던 경험을 공유 합니다.

동일한 주소로 Chrome에서는 정상적인 화면이 노출되는데 말이죠.

url 주소에 a=<script> 와 같은 파라미터를 강제로 입력하면 브라우저에서 자체적으로 XSS 공격으로 인식해서 뭔가 동작을 하는 것 같았습니다.

그런데 더 당황스러운건 동일한 파라미터를 네이버 검색에 적용했더니, 아래 화면 처럼 동일한 경고 메시지가 뜨긴 하지만 멀쩡한 화면이 그대로 노출된다는 사실이었습니다.

뭐지???

엄청난 삽질 끝에 알아낸 사실은 바로 응답 헤더 x-xss-protection 값 설정에 답이 있었습니다.

search.naver.com 도메인은 응답헤더에 x-xss-protection : 1; report=/p/er/post/xss 로 되어 있어서 정상적으로 노출되었고,

www.naver.com 도메인은 응답헤더에 x-xss-protection : 1; mode=block 으로 되어 있었습니다.

감이 오시죠? 

네, 맞습니다.

x-xss-protection : 1; mode=block 로 응답 헤더에 설정되어 있는경우

주소창에 xss 공격으로 의심되는 파라미터가 넘어오면,

화면 자체를 #(샵) 으로 block 시키는 것 같습니다. IE 님 만요.. ㅜㅜ

애초에 x-xss-protection 을 IE와 Safari만 지원하는 거였군요;;

(크롬도 제한적으로 지원하는 것 같긴한데..)

1. Google Chrome 브라우저를 엽니다.

2. 잠긴 PDF 파일을 Google Chrome 브라우저로 불러 옵니다.

3. 비밀번호를 입력해 PDF를 확인 합니다.

4. Ctrl + P 단축키를 눌러 인쇄 창이 뜨면 "대상" 항목을 "PDF로 저장" 으로 선택 후 인쇄 합니다.

- 끝 -

출처 : 금융결제원  http://www.kftc.or.kr/kftc/data/EgovBankListMove.do

코드 기관명

[대표코드]
001 한국은행
002 산업은행
003 기업은행
004 KB국민은행
007 수협은행
008 수출입은행
011 NH농협은행
012 지역농․축협
020 우리은행
023 SC제일은행
027 한국씨티은행
031 대구은행
032 부산은행
034 광주은행
035 제주은행
037 전북은행
039 경남은행
041 우리카드
044 외환카드
045 새마을금고
048 신협
050 저축은행
052 모건스탠리은행
054 HSBC은행
055 도이치은행
057 제이피모간체이스은행
058 미즈호은행
059 엠유에프지은행
060 BOA은행
061 비엔피파리바은행
062 중국공상은행
063 중국은행
064 산림조합중앙회
065 대화은행
066 교통은행
067 중국건설은행
071 우체국
076 신용보증기금
077 기술보증기금
081 하나은행
088 신한은행
089 케이뱅크
090 카카오뱅크
092 토스혁신준비법인
101 한국신용정보원
102 대신저축은행
103 에스비아이저축은행
104 에이치케이저축은행
105 웰컴저축은행
106 신한저축은행
209 유안타증권
218 KB증권
221 상상인증권
222 한양증권
223 리딩투자증권
224 BNK투자증권
225 IBK투자증권
227 KTB투자증권
238 미래에셋대우
240 삼성증권
243 한국투자증권
247 NH투자증권
261 교보증권
262 하이투자증권
263 현대차증권
264 키움증권
265 이베스트투자증권
266 SK증권
267 대신증권
269 한화투자증권
270 하나금융투자
271 토스준비법인
272 NH선물
278 신한금융투자
279 DB금융투자
280 유진투자증권
287 메리츠증권
288 카카오페이증권
290 부국증권
291 신영증권
292 케이프투자증권
293 한국증권금융
294 한국포스증권
295 우리종합금융
299 우리금융캐피탈
361 BC카드
364 광주카드
365 삼성카드
366 신한카드
367 현대카드
368 롯데카드
369 수협카드
370 씨티카드
371 NH카드
372 전북카드
373 제주카드
374 하나SK카드
381 KB국민카드
401 하나생명보험
402 동양생명
431 미래에셋생명
432 한화생명
433 교보라이프플래닛생명
434 푸본현대생명
435 라이나생명
436 교보생명
437 에이비엘생명
438 신한생명
439 KB생명보험
440 농협생명
441 삼성화재
442 현대해상
443 DB손해보험
444 KB손해보험
445 롯데손해보험
446 오렌지라이프생명보험
447 악사손해보험
448 메리츠화재
449 농협손해보험
450 푸르덴셜생명
452 삼성생명
453 흥국생명
454 한화손해보험
455 AIA생명
456 DGB생명보험
457 DB생명보험
458 KDB생명보험
459 에이스아메리칸화재해상보험
460 처브라이프
469 금융정보분석원

[은행]
001 한국은행
002 산업은행
003 기업은행
004 KB국민은행
005 하나은행
006 KB국민은행
007 수협은행
008 수출입은행
009 수협은행
010 NH농협은행
011 NH농협은행
012 지역 농축협
013 지역 농축협
014 지역 농축협
015 지역 농축협
016 NH농협은행
017 지역 농축협
018 지역 농축협
019 KB국민은행
020 우리은행
021 신한은행
022 우리은행
023 SC제일은행
024 우리은행
025 하나은행
026 신한은행
027 한국씨티은행
028 신한은행
029 KB국민은행
030 수협은행
031 대구은행
032 부산은행
033 하나은행
034 광주은행
035 제주은행
036 한국씨티은행
037 전북은행
038 기타
039 경남은행
040 기타
041 우리카드
042 기타
043 기업은행
044 하나카드
045 새마을금고
046 새마을금고
047 신협
048 신협
049 신협
050 저축은행
051 기타 외국계은행(중국 농업은행 등)
052 모간스탠리은행
053 한국씨티은행
054 HSBC은행
055 도이치은행
056 기타
057 제이피모간체이스은행
058 미즈호은행
059 엠유에프지은행
060 BOA은행
061 비엔피파리바은행
062 중국공상은행
063 중국은행
064 산림조합중앙회
065 대화은행
066 교통은행
067 중국건설은행
068 기타
069 기타
070 기타
071 우체국
072 우체국
073 우체국
074 우체국
075 우체국
076 신용보증기금
077 기술보증기금
078 KB국민은행
079 KB국민은행
080 하나은행
081 하나은행
082 하나은행
083 우리은행
084 우리은행
085 새마을금고
086 새마을금고
087 새마을금고
088 신한은행
089 케이뱅크
090 카카오뱅크
092 토스혁신준비법인
102 대신저축은행
103 에스비아이저축은행
104 에이치케이저축은행
105 웰컴저축은행
106 신한저축은행

100% — FF
95% — F2
90% — E6
85% — D9
80% — CC
75% — BF
70% — B3
65% — A6
60% — 99
55% — 8C
50% — 80
45% — 73
40% — 66
35% — 59
30% — 4D
25% — 40
20% — 33
15% — 26
10% — 1A
5% — 0D
0% — 00

* Firebase 프로젝트가 이미 생성된 상태를 가정합니다.

1. Firebase 콘솔 > 프로젝트 > Hosting 화면

2. '시작하기'를 클릭하면 아래화면이 뜹니다.

3.  설명대로 cmd창에서 'npm install -g firebase-tools'를 실행합니다.

- npm이 미리 설치되어 있어야 합니다.

-2017/06/21 - [Tool] - npm 사용을 위한 Node.js 설치 Window 2017.06

4. "2번" 에서 '다음'을 클릭하면 나오는 화면 입니다.

5. firebase login 실행시 나오는 화면입니다.

- 오류 발생시 firebase가 수집하는 허락할건지 묻는 겁니다.

6. Y나 n을 선택하면 브라우저를 통해 구글 계정으로 권한을 요청합니다.

7. 권한 허용 후 화면입니다.

8. 권한 허용 프로세스가 끝나고 cmd로 돌아와 보면 아래 화면이 나타납니다.

9. "4번" 설명의 두 번째 명령어 'firebase init'을 실행 합니다.

- 주의 : 저는 처음에 C:\ 위치에서 명령어를 실행했다가 삽질을 좀 했습니다.

- firebase 프로젝트 홈이 될 디렉토리를 생성 후 그곳으로 이동해서 명령어를 실행해야 합니다.

- 예시) D:\project\firebasecli > fireabse init

10.  Are you ready to proceed? (Y/n) 에서 Y를 누르면 나오는 화면 입니다.

- Firebase 서비스들이 나열되어서 이용할 서비스를 space 로 선택하면 됩니다.

- 화살표 키로 Hosting으로 이동 후 스페이스로 선택후 엔터를 누릅니다.

11. 호스팅 홈 디렉터리를 지정합니다.

- 그냥 엔터를 치면 firebase init을 실행했던 위치의 상대경로 + public 폴더가 새로 생성됩니다.

12. Configure as a single-page app (rewrite all ruls to /index.html)?

- SPA 하나의 페이지 앱을 만들건지 묻습니다. No를 선택합니다.

13. No를 선택하면 요런 파일들이 생성됩니다.

14. "4번" 도움말에서 '다음' 을 클릭하면 나오는 화면 입니다.

15. 설명에 따라 firebase deploy 를 실행 합니다.

16. Deploy가 완료 되었습니다.

- 아까 생성되었던 index.html를 브라우저에서 url을 입력해 확인이 가능합니다.

2020/07/21 - [기타] - 이더리움 기반 ERC-20 토큰 만들기(1부) :: 2020.07

1부에 이어 계속 하겠습니다.

2. Github 설정

- URL : https://github.com/OpenZeppelin/openzeppelin-contracts/tree/v2.5.1

- 현재 최신 버전은 3.1.0 이지만 토큰 생성 가이드는 2.5.1 버전만 존재함.

- https://github.com/OpenZeppelin/openzeppelin-contracts/tree/v2.5.1/contracts/token/ERC20 로 이동

3. Remix 설정

- URL : http://remix.ethereum.org/

- 별도 가입 없음.

- 메타마스크와 같은 브라우저에서 열어야 함.

- 초기화면

- 아래 빨간박스 "GitHub"를 클릭합니다.

- 아래 팝업이 뜨면 "2. GitHub 설정" 의 화면에서 6개 파일의 주소를 넣어서 차례대로 Import 합니다.

- 6개 파일의 주소는 아래와 같습니다.

ERC20.sol : https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/token/ERC20/ERC20.sol

IERC20.sol : https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/token/ERC20/IERC20.sol

Context.sol : https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/GSN/Context.sol

SafeMath.sol : https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/math/SafeMath.sol

SimpleToken.sol : https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/examples/SimpleToken.sol

ERC20Detailed.sol :  https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/token/ERC20/ERC20Detailed.sol

- 6개를 모두 Import 하면 다음 화면 처럼 됩니다.

- 이렇게 되면 토큰 하나를 만들 준비가 다 된 겁니다.

- 다음은 이더리움 소스들을 컴파일 하는 순서입니다.

- 1) 컴파일 전에 먼저 SimpleToken.sol 파일을 열어서 아래 화면 처럼 사용할 토큰명, 심볼, 발행량을 수정합니다.

- 2) 왼쪽 메뉴의 두번째 아이콘이 컴파일러 메뉴 입니다. 

- 3) 솔리디티 컴파일러 메뉴가 나타나면 "Compile SimpleToken.sol" 을 클릭합니다.

- 컴파일이 성공적으로 끝났다면 이번엔 배포할 차례 입니다.

- 1) 왼쪽 메뉴의 3번째 아이콘을 클릭합니다.

- 2) 배포 메뉴가 나타나면 ENVIRONMENT(환경)을 Injected Web3 로 변경 합니다.

- Remix를 처음 사용하는 경우 메타마스크를 통해 자동으로 인증을 시켜줍니다.

- 인증이 완료되면, 배포할 ACCOUNT(계정)와 CONTRACT(계약)이  나타나게 됩니다.

- CONTRACT는 SimpleToken으로 선택하고 Deploy(배포)를 클릭합니다.

- 새로운 토큰을 배포하면 GAS FEE(가스비)가 듭니다.

- 가스비는 1부에서 파우셋을 통해 무료로 받은 5이더 중에서 나가게 됩니다.

- 컨트랙트 배포가 승인되었습니다.!!

- 오른쪽 부분의 빨간박스로 된 화살표를 누르면 배포된 내용을 이더스캔 사이트에서 확인할 수 있습니다.

- 테스트 환경인 ropsten.etherscan.io 사이트로 이동되서 내용이 보입니다.

- 빨간 박스 부분의 토큰명을 클릭 합니다.

- 메타마스크에 토큰을 추가할 때 필요하므로 빨간 박스 부분의 Contract 주소를 복사해 둡니다.

- 이제 우리가 만든 토큰을 메타마스크에 추가해 보겠습니다.

- 아래 화면의 빨간박스에 있는 "토큰 추가"를 클릭합니다.

- "사용자 정의 토큰"을 클릭합니다.

- 아까 복사해 두었던 주소를 붙여넣기 합니다.

- 드디어 토큰이 추가 되었습니다.

1. 메타마스크 설정

- URL : https://chrome.google.com/webstore/detail/metamask/nkbihfbeogaeaoehlefnkodbefgpgknn?hl=ko

- 크롬 확장 프로그램으로 설치합니다.

- 설치되면 나타나는 첫 화면 입니다.

- 사용자 인증을 하는 화면 입니다.

- 처음 사용하는 사용자라면 "지갑 생성하기" 를 클릭합니다.

- 메타마스크 사용 정보를 전송할 것인지 묻는 화면 입니다.

- 어떤 걸 선택하셔도 상관 없습니다.

- 메타마스크 비밀번호를 생성합니다.

- 비밀번호 생성 후 "비밀 백업 구문" 을 알려 줍니다.

- 여러 단어들이 의미없이 나열되어 있는 형태 입니다.

- 이 백업 구문이 있어야 나중에 계정을 복구 하거나 다른 컴퓨터에서도 동일하게 메타마스크를 사용할 수 있습니다.

- 백업 구문의 순서를 확인합니다.

- 비밀번호 재확인 같은 겁니다.

- 메타마스크 계정을 생성 완료 했습니다.

- 로그인 후 첫 화면 입니다.

- 우측 상단의 "이더리움 메인넷" 을  선택해서 "Ropsten 테스트넷" 으로 변경합니다.

- 메인넷은 실제 환경이고 테스트넷은 말 그대로 테스트 할 수 있는 환경입니다.

- 테스트 환경에서 연습해보고 나중에 메인넷에서 다시 제대로 만들 수 있습니다.

- 우측 상단의 "입금" 버튼을 클릭합니다.

- "파우셋 테스트" 를 이용하면 테스트 환경에서 무료로 이더를 얻을 수 있습니다.

- "이더 얻기" 버튼을 클릭 합니다.

- 이더가 있어야 토큰을 생성할 수 있기 때문에 이 과정이 필요합니다.

- 메인넷에서는 실제 이더가 있어야 하겠죠.

- "request 1 ether from faucet" 를 클릭 합니다.

- 파우셋으로 부터 1 이더를 요청하는 겁니다.

- 파우셋을 처음 이용하는 경우 뜨는 화면 입니다.

- 메타테스크 계정으로 인증하는 절차입니다.

- "연결" 버튼을 클릭합니다.

- 인증이 되고 나면 이전 화면에서 undefined라고 나오던 user 정보가 설정이 됩니다.

- 5번 까지 "request 1 ether from faucet" 버튼을 클릭 합니다.

- 6번 부터는 "error":"User is greedy - already has too much ether"} 오류가 발생 합니다.

- 5 이더가 입급 되었습니다.

2020/07/23 - [개발자] - 이더리움 기반 ERC-20 토큰 만들기(2부) :: 2020.07