Awesome Application Security Checklist

굉장한 응용 보안-체크리스트

보안을 염두에두고 웹/모바일 애플리케이션을 디자인, 작성, 테스트하는 경우이 반 측정 점검표가 좋은 출발점이 될 수 있습니다.

인증 시스템 (가입/사인/2 팩터/비밀번호 재설정)

• 어디에서나 https를 사용하십시오.
• Bcrypt 사용하여 암호 해시를 저장하십시오 (소금 필요 없음 Bcrypt 당신을 위해 그것을합니다).
• logout 후 세션 식별자를 파괴하십시오.
• 비밀번호에 대한 모든 활성 세션을 파괴하십시오 (또는 제안).
• OAUTH2에 state 매개 변수가 있어야합니다.
• 성공적인 로그인 후 또는 다른 중간 리디렉션에서 열린 리디렉션이 없습니다.
• 가입/로그인 입력을 구문 분석 할 때 JavaScript : //, data : //, crlf 문자를 소독하십시오.
• 안전하고 httponly 쿠키를 설정하십시오.
• 모바일 OTP 기반 모바일 검증에서 generate OTP 하거나 Resend OTP 때 응답으로 OTP를 다시 보내지 마십시오.
• Login 시도하고, Verify OTP , Resend OTP 하고 특정 사용자에 대한 generate OTP 시도. 지수 백 오프 세트 또는/및 보안 문자 기반 도전과 같은 것을 가지고 있습니다.
• 이메일 링크 또는 SMS에서 비밀번호 토큰 리셋의 임의성을 확인하십시오.
• 합리적인 기간 동안 재설정 비밀번호 토큰을 만료하십시오.
• 재설정 토큰을 성공적으로 사용한 후 만료하십시오.

사용자 데이터 및 인증

• my cart , my history 와 같은 리소스 액세스는 세션 ID를 사용하여 로그인 한 리소스의 사용자 소유권을 확인해야합니다.
• 연속적으로 반복 가능한 리소스 ID를 피해야합니다. / /user/37153/orders /me/orders 주문. 이는 승인 토큰을 확인하는 것을 잊어 버린 경우 정신 점검 역할을합니다.
• Edit email/phone number 기능에는 계정 소유자에게 확인 이메일을 동반해야합니다.
• 업로드 기능은 사용자가 제공 한 파일 이름을 소독해야합니다. 또한 일반적으로 보안과는 별도로 Code를 실행할 수있는 서버가 아니라 S3 (및 Lambda를 사용한 후 프로세스)에 업로드하십시오.
• Profile photo upload 기능은 필요하지 않은 경우 모든 EXIF ​​태그를 소독해야합니다.
• 사용자 ID 및 기타 ID의 경우 정수 대신 RFC 준수 UUID 사용하십시오. GitHub에서 언어에 대한 구현을 찾을 수 있습니다.
• JWT는 굉장합니다. 단일 페이지 앱/API에 필요한 경우 사용하십시오.

데이터 베이스

• 사용자 식별 데이터 및 액세스 토큰, 이메일 주소 또는 청구 세부 사항과 같은 민감한 데이터에 암호화를 사용하십시오.
• 데이터베이스가 AWS Aurora와 같은 저렴한 비용 암호화를 지원하는 경우 디스크에서 데이터를 보호 할 수 있습니다. 모든 백업이 암호화되어 있는지 확인하십시오.
• 데이터베이스 액세스 사용자 계정에 최소한의 권한을 사용하십시오. 데이터베이스 루트 계정을 사용하지 마십시오.
• 목적을 위해 설계된 키 스토어를 사용하여 비밀을 저장하고 배포하십시오. 응용 프로그램에서 하드 코드를하지 마십시오.
• SQL 제조 된 명령문 만 사용하여 SQL 주입을 완전히 방지하십시오. 예를 들어, NPM을 사용하는 경우 NPM-MYSQL을 사용하지 마십시오. 준비된 문을 지원하는 NPM-MYSQL2를 사용하십시오.

Android / iOS 앱

• 결제 게이트웨이의 salt 하드 코딩되어서는 안됩니다.
• 제 3 자 SDK의 secret / auth token 하드 코딩되어서는 안됩니다.
• API 호출은 server to server 수행되도록 의도 된 앱에서 수행해서는 안됩니다.
• 안드로이드에서는 모든 부여 된 권한을 신중하게 평가해야합니다.
• iOS에서 시스템 키 체인에 민감한 정보 (인증 토큰, API 키 등)를 저장하십시오. 사용자 기본값에 이러한 종류의 정보를 저장 하지 마십시오 .
• 인증서 고정을 적극 권장합니다.

보안 헤더 및 구성

• CSP 헤더를 Add XSS 및 데이터 주입 공격을 완화하십시오. 이것은 중요합니다.
• 크로스 사이트 요청 위조를 방지하기 위해 CSRF 헤더를 Add . 또한 쿠키에 Samesite 속성을 추가하십시오.
• SSL 스트리핑 공격을 방지하기 위해 HSTS 헤더를 Add .
• 도메인을 HSTS 예압 목록에 Add
• X- 프레임 옵션을 Add 클릭 재킹으로부터 보호하십시오.
• XSS 프로테리 헤더를 Add XSS 공격을 완화하십시오.
• DNS 레코드를 업데이트하여 SPF 레코드를 추가하여 스팸 및 피싱 공격을 완화하십시오.
• 제 3 자 CDN에서 JavaScript 라이브러리를로드하는 경우 하위 소스 무결성 점검을 추가하십시오. 추가 보안을 위해 SRI SAT가없는 리소스를로드하지 않도록 요구 사항 스프로 CSP 지정을 추가하십시오.
• 임의의 CSRF 토큰을 사용하고 HTTP 게시물 요청으로 비즈니스 로직 API를 노출하십시오. 예를 들어 초기 요청 업그레이드 단계에서 CSRF 토큰을 HTTP에 노출시키지 마십시오.
• GET 요청 매개 변수에서 임계 데이터 또는 토큰을 사용하지 마십시오. 서버 로그 또는 머신/스택 처리 노출로 인해 사용자 데이터가 차례로 노출됩니다.

입력의 소독

• XSS를 방지하기 위해 모든 사용자 입력 또는 사용자에게 노출 된 입력 매개 변수를 Sanitize .
• SQL 주입을 방지하기 위해 항상 매개 변수화 쿼리를 사용하십시오.
• CSV 가져 오기와 같은 기능에 직접 사용하는 경우 사용자 입력을 소독하십시오.
• coolcorp.io/username과 같은 URL 패턴을 사용하는 경우 프로필 이름으로 Robots.txt와 같은 특수 사례의 사용자 입력을 Sanitize .
• 물체가 아무리 작더라도 문자열 연결에 의해 코드 또는 JSON을 직접 구축하지 마십시오. 언어 정의 된 라이브러리 또는 프레임 워크를 사용하십시오.
• SSRF를 방지하기 위해 일종의 URL을 사용하는 입력을 소독합니다.
• 사용자에게 표시하기 전에 출력을 소독합니다.

서비스 보호 거부

• API에 대한 DOS 공격이 사이트를 무자비하지 않도록하십시오. 최소한 로그인 및 토큰 생성 루틴과 같은 느린 API 경로에 속도 제한자가 있습니다. DOS로부터 백엔드 서비스를 보호하기 위해 프론트 엔드 API의 Captcha를 고려하십시오.
• 사용자 제출 데이터 및 요청의 크기 및 구조에 대한 세력 제한을 시행합니다.
• CloudFlare와 같은 글로벌 캐싱 프록시 서비스를 통한 DDOS (Distributed Denial of Service) 완화를 사용하십시오. DDOS 공격을 겪고 있으면 DNS 조회로 기능하면 켜질 수 있습니다.

운영

• 작고 경험이 부족한 경우 AWS Elasticbeanstalk 또는 PAAS를 사용하여 코드를 실행하십시오.
• 괜찮은 프로비저닝 스크립트를 사용하여 클라우드에서 VM을 생성하십시오.
• 공개적으로 open ports 없는 기계를 확인하십시오.
• databases , 특히 mongodb & redis의 없음/기본 비밀번호를 확인하십시오.
• SSH를 사용하여 기계에 액세스하십시오. 비밀번호를 설정하지 말고 대신 SSH 키 기반 인증을 사용하십시오.
• Heartbleed, Shellshock과 같은 제로 데이 취약점에 적시에 업데이트를 설치하십시오.
• 서버 구성을 수정하여 HTTPS에 TLS 1.2를 사용하고 다른 모든 체계를 비활성화하십시오. (트레이드 오프가 좋습니다.)
• 디버그 모드를 켜지 마십시오. 일부 프레임 워크에서 디버그 모드는 액세스 본격적인 대체 또는 쉘을 제공하거나 오류 메시지 스택 트레이스에 중요한 데이터를 노출시킬 수 있습니다.
• 나쁜 행위자 및 DDOS에 대비하십시오 - DDOS 완화가있는 호스팅 서비스를 사용하십시오.
• 시스템에 대한 모니터링을 설정하고 물건을 기록하십시오 (새로운 유물 또는 이와 유사한 것을 사용하십시오).
• 엔터프라이즈 고객을 위해 개발하는 경우 규정 준수 요구 사항을 준수하십시오. AWS S3 인 경우 기능을 사용하여 데이터를 암호화하는 것을 고려하십시오. AWS EC2를 사용하는 경우 기능을 사용하여 암호화 된 볼륨을 사용하는 것을 고려하십시오 (현재 부팅 볼륨도 암호화 할 수 있음).

클라우드 구성

• 모든 서비스에 최소 포트가 열려 있는지 확인하십시오. 모호함을 통한 보안은 보호는 아니지만 비표준 포트를 사용하면 공격자에게 조금 더 어려워집니다.
• 공개 네트워크에서 보이지 않는 개인 VPC에서 백엔드 데이터베이스 및 서비스를 호스트합니다. AWS 보안 그룹을 구성 할 때 매우주의를 기울여야합니다.
• 별도의 VPC 및 피어 VPC로 논리 서비스를 분리하여 서비스 간 통신을 제공합니다.
• 모든 서비스가 최소한의 IP 주소 세트에서만 데이터 만 허용하는지 확인하십시오.
• 나가는 IP 및 포트 트래픽을 제한하여 APT 및 "Botification"을 최소화하십시오.
• 루트 자격 증명이 아닌 항상 AWS IAM 역할을 사용하십시오.
• 모든 OPS 및 개발자 직원에게 최소 액세스 권한을 사용하십시오.
• 일정에 따라 비밀번호와 액세스 키를 정기적으로 회전시킵니다.

CI & CD는 장치/통합 테스트 범위를 통해 설계 및 구현을 감사합니다. 코드 검토 프로세스를 사용하고 자기 승인을 무시하십시오. 공급 업체 라이브러리 및 기타 종속성을 포함하여 생산으로 추진하기 전에 AV 소프트웨어에 의해 서비스의 모든 구성 요소가 정적으로 스캔되도록하십시오. 배포를위한 롤백 솔루션을 설계하십시오.

사람들

• 이메일 (예 : [email protected])과 보안 연구원이 취약점을보고 할 페이지를 설정하십시오.
• 당신이 만들고있는 것에 따라 사용자 데이터베이스에 대한 액세스를 제한하십시오.
• 버그 기자에게 예의 바르게 행동하십시오.
• 안전한 코딩 관점에서 동료 개발자가 코드 검토를 수행하십시오. (더 많은 눈)
• 해킹 또는 데이터 위반의 경우 데이터 액세스에 대한 이전 로그를 확인하십시오. 사람들에게 비밀번호를 변경하도록 요청하십시오. 설립 된 위치에 따라 외부 대행사의 감사가 필요할 수 있습니다.

하부 구조

• 다운 타임없이 업그레이드를 수행 할 수 있는지 확인하십시오. 완전히 자동화 된 방식으로 소프트웨어를 신속하게 업데이트 할 수 있는지 확인하십시오.
• 클라우드 콘솔이 아닌 Terraform과 같은 도구를 사용하여 모든 인프라를 만듭니다. 인프라는 "코드"로 정의되어야하며 버튼을 푸시 할 때 다시 만들 수 있어야합니다. 클라우드에서 손으로 생성 된 모든 리소스에 대한 공차가 없습니다. Terraform은 구성을 감사 할 수 있습니다.
• 모든 서비스에 중앙 집중식 로깅을 사용하십시오. 로그에 액세스하거나 검색하기 위해 SSH가 필요하지 않아야합니다.
• 일회성 진단을 제외하고는 서비스에 SSH를하지 마십시오. SSH를 정기적으로 사용하면 일반적으로 중요한 작업을 자동화하지 않았 음을 의미합니다.
• AWS 서비스 그룹에서 포트 22를 열어 두지 마십시오. 대신 상자에서 승인 된 IP 만 SSH로 허용하는 것을 고려하십시오.
• 패치 및 업그레이드하는 장기 서버 대신 불변의 호스트를 만듭니다. (불변 인프라가 더 안전 할 수 있음).
• APT를 최소화하기 위해 Sensedeep 또는 Service와 같은 침입 탐지 시스템을 사용하십시오.