모든 프로그래머는 보안에 대해 무엇을 알아야합니까? [닫은]

427

저는 IT 학생이며 현재 대학교 3 학년입니다. 지금까지 우리는 일반적인 컴퓨터 (프로그래밍, 알고리즘, 컴퓨터 아키텍처, 수학 등)와 관련된 많은 주제를 연구했습니다.

나는 아무도 보안에 대해 모든 것을 배울 수는 없지만 모든 프로그래머 나 IT 학생이 알아야 할 "최소한"지식이 있고 내 질문은이 최소한의 지식이 무엇인지 확신합니다.

전자 책이나 코스를 제안하거나이 도로를 시작하는 데 도움이 될만한 것이 있습니까?

security 
— MH
소스
6
— Thomas
118
규칙 # 1 : 사용자 입력을 신뢰하지 마십시오. 할머니 인 경우에도
— Anthony Forloney
2
- .. 그리고이 스레드는 또한 훌륭한 정보가 stackoverflow.com/questions/72394/...
— Sripathi Krishnan
내 질문은 프로그래머와 실수뿐만 아니라 IT 및 컴퓨터 과학 학생에 관한 것이 아닙니다
— Mohamad Alhamoud
1
오류 메시지를보십시오. 사용하기 편하지만 "이 계정이 존재하지 않습니다"와 "암호가 유효하지 않습니다"의 차이는 경우에 따라 위험 할 수 있습니다.
— Michael Mior

답변:

551

애플리케이션 보안을 원할 경우 다음 사항을 명심하십시오.

  • 어떤 입력도 믿지 마십시오!
  • 신뢰할 수없는 모든 소스의 입력 확인 -블랙리스트가 아닌 화이트리스트 사용
  • 처음부터 보안을 계획하십시오-결국에는 볼트로 고정 할 수있는 것이 아닙니다
  • 단순성 유지-복잡성으로 인해 보안 허점 가능성 증가
  • 당신의 계속 공격 표면을 최소로
  • 안전하게 실패 했는지 확인하십시오
  • 심층 방어 사용
  • 최소 특권 원칙 준수
  • 위협 모델링 사용
  • 구획화 -시스템이 전부가 아님
  • 비밀을 숨기는 것은 어렵고 코드에 숨겨진 비밀은 오랫동안 비밀로 유지되지 않습니다.
  • 자신의 암호를 작성하지 마십시오
  • 암호화를 사용한다고해서 안전하다는 의미는 아닙니다 (공격자가 약한 링크를 찾습니다)
  • 알고 있어야 버퍼 오버 플로우 와이를 방지하기 위해

응용 프로그램 보안에 관한 온라인 서적과 기사는 다음과 같습니다.

응용 프로그램 보안에 대한 최고의 실무에 대한 개발자 교육

코드 바싱 (유료)

보안 혁신 (유료)

보안 나침반 (유료)

OWASP WebGoat (무료)

— 숫자
소스
+1 "소프트웨어 활용 : 코드를 깨는 방법"은 훌륭한 책이지만 링크 된 슬라이드 쇼는 끔찍합니다.
— rook
7
그러나 불행히도 현대 시스템에서 최소 권한의 원칙을 인스턴스화하는 것은 거의 불가능합니다. 예를 들어, Linux 커널 (현재 사용중인 소스)에는 9,400 만 라인 이상의 C 코드와 400K 라인 이상의 어셈블리가 포함되어 있으며 모두 제한되지 않은 컨텍스트에서 실행됩니다. 이 수백만 줄 중 하나에서 간단한 계산 오류 (의도적)는 전체 시스템을 손상시킵니다. 아마도 다음 세기 나 2 년 안에 아무도 실제로 안전한 OS / 언어 / 프레임 워크를 만드는 것에 관심이 없기 때문에 해결책이 나오지 않을 것입니다.
— L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳
1
"웹 응용 프로그램 해커 핸드북"을 해당 목록에 추가합니다.
— 17:07에
34
"사용자 입력을 절대 신뢰하지 마십시오!" "입력 내용을 절대 신뢰하지 마십시오!" 다른 소프트웨어에서 들어오는 입력은 사용자 입력과 동일하게 취급되어야합니다. 예를 들어, 웹 사이트 로깅에서 대부분의 사람들은 User-Agent / 브라우저 ID 필드를 '사용자 입력'으로 생각하지 않지만 쉽게 포함 할 수 있습니다. SQL 주입.
— Peteris
2
@ L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ 음, .NET에 구축 된 Microsoft Research 실험용 OS (단일성)가 안전을 주요 목표 (버퍼 오버플로 없음)로 목표로 삼았습니다. 프로세스 메모리 공유, 코드 자체 수정, 장치 드라이버조차도 .NET의 다른 소프트웨어 격리 프로세스 일뿐입니다. 꽤 흥미로운 개념이지만, 이것을 사람들에게 전달하는 것은 매우 어려울 것입니다 (가장 중요한 것은 기존 소프트웨어 또는 드라이버와의 역 호환성을 수행 할 수는 없습니다.
— Luaan
102

프로그래머를위한 보안 규칙 # 1 : 자신을 굴리지 마십시오

보안 전문가 및 / 또는 암호 전문가가 아니라면 항상 잘 설계되고 테스트를 거친 성숙한 보안 플랫폼, 프레임 워크 또는 라이브러리를 사용하여 작업하십시오. 이러한 것들은 전문가와 해커 모두가 생각하고, 패치하고, 업데이트하고, 검사하는 데 몇 년이 걸렸습니다. 휠을 재발 명하여 이러한 이점을 없애고 싶지는 않습니다.

이제는 보안에 대해 배울 필요가 없습니다. 현재하고있는 일을 이해하고 도구를 올바르게 사용하고 있는지 충분히 알아야합니다. 그러나 자체 암호화 알고리즘, 인증 시스템, 입력 소독제 등을 작성하기 시작한 경우 중지하고 한 발 물러나서 규칙 # 1을 기억하십시오.

— 타일러 맥 헨리
소스
10
이것은 제 생각에는 나쁜 규칙입니다. 자산에 대한 실질적인 관심이 아니라 선택한 플랫폼으로 인해 기본적으로 타겟팅 할 수 있습니다. 타사 플랫폼에서 발견되는 모든 보안 허점과 사용하기 때문에 즉시 취약한 모든 제품에 대해 생각해보십시오. 보안을 제 3 자에게 너무 빨리 믿지 않을 것입니다.
— Fosco
9
나는 이것이 암호화에 대한 좋은 규칙이라고 생각합니다. 자신 만의 암호화를 굴리는 것은 재앙의 요리법입니다. 그러나 Fosco가 지적한 것처럼 자신의 블로그 엔진을 롤링하는 것이 더 안전 할 수 있습니다. 자신을 롤링하면 워드 프레스 설치가 처리해야하는 자동 공격에 덜 걸릴 수 있습니다.
— James P McGrath
5
암호화에 관해서는이 규칙이 절대적입니다. 자신의 암호, 기간을 쓰지 마십시오. 타사 플랫폼 사용과 관련하여 다릅니다. 일부 플랫폼은 본질적으로 더 안전하고 일부 플랫폼은 본질적으로 덜 안전하며 대부분의 플랫폼은 일부 보안 기능뿐만 아니라 알려진 공격 경로도 제공합니다. github에서 보안 허점을 일으킨 최근 Rails 취약점을 해결 하십시오 . 의심 할 여지없이 Rails는 많은 보안 기능을 제공하지만 기본 설정이 안전하지 않은 강력한 기능도 있습니다.
— Michael Kopinsky
7
암호화에 관해서는 자신의 것을 굴리지 말고 사용중인 것을 이해하십시오. 두 개의 메시지에 대해 RC4에 동일한 암호화 키를 사용하는 것이 끔찍한 이유를 이해하지 못하는 경우 예를 들어 스트림 암호를 사용하기 전에 읽어보십시오.
— Christopher Creutzig
3
HeartBleed 버그 이후에도 이것이 좋은 규칙임이 분명합니다. 커스텀 프로젝트 나 독점 프로젝트에서 열에 휩싸인 벌레를 찾는 것이 얼마나 어려울 지 상상해보십시오. 당신이 자신의 롤을하면, 당신은 모호한 뒤에 숨어 있고 어떤 버그가 악용 될 수 있는지 모릅니다.
— Sqeaky
71

모든 프로그래머는 익스플로잇 코드를 작성하는 방법을 알고 있어야합니다.

시스템이 어떻게 악용되는지 알지 못하면 실수로 취약점을 막고 있습니다. 패치를 테스트하는 방법을 모른다면 코드 패치 방법을 아는 것은 절대 의미가 없습니다. 보안은 단순한 생각 실험이 아니라 과학적이고 실험을 테스트해야합니다.

— 루크
소스
10
나는 이것이 전혀 필요하지 않다고 주장한다. 공격자가 어떤 종류의 메모리 손상을 일으킬 수 있다면 자신의 소유라고 생각하십시오. 실제로 작성 (작동) 익스플로잇에 대해 자세히 설명 할 필요가 없습니다.
— newgre
6
@newgre 모든 취약점이 버퍼 오버 플로우 인 것은 아닙니다. Common Weakness Enumeration 시스템에 포함 된 수천 가지 취약점이 있습니다. 프로그래머는 공격자의 마음을 이해해야합니다. 그렇지 않으면 실수를 모르고있을 것입니다.
— rook
1
나는 그들 모두가 버퍼 오버플로가 아니라는 것을 알고 있지만 일반적으로 "취약"이라고 불리는 것은 일종의 메모리 손상을 기반으로합니다 : 버퍼 오버플로, 더블 프리, 힙 오버플로, 정수 관련 오버플로, 형식 문자열 물론 로직 버그와 같은 다른 것들이 있지만,이 답변의 주제는 처음에는 아닙니다.
— newgre
5
@newgre 이는 일종의 악용이지만, 오늘날 메모리 손상 문제보다 웹 응용 프로그램 결함을 활용하기 위해 더 많은 악용이 작성되었습니다. 익스플로잇은 SQL 인젝션, 로컬 파일 포함, CSRF 및 XSS를 사용하여 작성되며 일반적인 문제입니다. (출처 : exploit-db.com )
— rook
1
본인이 익스플로잇을 작성할 수 있다면 최대로 해커의 마음에 갈 수있는 것에 대해 이해할 수 있습니다.
— linuxeasy
42

보안은 제품이 아닌 프로세스입니다.

많은 사람들이이 명백한 사실을 잊어 버리는 것 같습니다.

— 에릭 테 버트
소스
23

CWE / SANS TOP 25 가장 위험한 프로그래밍 오류를 검토하는 것이 좋습니다 . 향후 정기 업데이트를 약속하여 2010 년에 업데이트되었습니다. 2009 개정도 사용할 수 있습니다.

에서 http://cwe.mitre.org/top25/index.html

2010 CWE / SANS Top 25 가장 위험한 프로그래밍 오류는 심각한 소프트웨어 취약점으로 이어질 수있는 가장 광범위하고 중요한 프로그래밍 오류 목록입니다. 그들은 종종 찾기 쉽고 착취하기 쉽습니다. 공격자는 소프트웨어를 완전히 인수하거나 데이터를 훔치거나 소프트웨어가 전혀 작동하지 않도록하기 때문에 위험합니다.

상위 25 개 목록은 교육 및 인식을위한 도구로, 프로그래머가 소프트웨어를 출하하기 전에 발생하는 너무 일반적인 실수를 식별하고 피함으로써 소프트웨어 산업을 괴롭히는 취약점을 예방할 수 있도록 도와줍니다. 소프트웨어 고객은 동일한 목록을 사용하여보다 안전한 소프트웨어를 요청할 수 있습니다. 소프트웨어 보안 연구원은 Top 25를 사용하여 알려진 모든 보안 취약점의 좁지 만 중요한 부분에 집중할 수 있습니다. 마지막으로, 소프트웨어 관리자 및 CIO는 소프트웨어 보안을 유지하기위한 노력의 척도로서 Top 25 목록을 사용할 수 있습니다.

— jschmier
소스
1
이 목록의 상위 4 개 오류 (및 기타 여러 오류)는 모두 동일한 오류 (입력 신뢰)입니다.
— Chris Dodd
13

좋은 시작 코스는 컴퓨터 네트워크 및 보안 의 MIT 코스 일 수 있습니다 . 내가 제안 할 한 가지는 프라이버시를 잊지 않는 것입니다. 어떤 의미에서 개인 정보 보호는 실제로 보안의 기초가되며 보안에 대한 기술 과정에서는 다루지 않습니다. 이 과정에서 인터넷과 관련된 윤리 및 법률 에 관한 개인 정보에 대한 자료를 찾을 수 있습니다 .

— Tvanfosson
소스
MIT 과정 링크가 작동하지 않음
— AntonioCS
1
링크가 수정되었습니다 (현재). 감사.
— tvanfosson
8

프레임 워크 및 API에서 보안 기본값의 중요성 :

  • 초기 웹 프레임 워크의 많은 부분은 기본적으로 템플릿에서 HTML을 이스케이프하지 않았기 때문에 XSS 문제가있었습니다.
  • 초기 웹 프레임 워크가 많으면 매개 변수화 된 쿼리를 작성하는 것보다 SQL을 연결하는 것이 쉬워 져 많은 SQL 주입 버그가 발생합니다.
  • 일부 Erlang 버전 (R13B, 기타 버전)은 기본적으로 SSL 피어 인증서를 확인하지 않으며 SSL MITM 공격에 취약한 많은 Erlang 코드가있을 수 있습니다.
  • Java의 XSLT 변환기는 기본적으로 임의의 Java 코드를 실행할 수 있습니다. 이로 인해 많은 심각한 보안 버그가 발생했습니다.
  • Java의 XML 구문 분석 API는 기본적으로 구문 분석 된 문서가 파일 시스템에서 임의의 파일을 읽을 수 있도록합니다. 더 재미있는 :)
— 벤 무머
소스
5

세 A에 대해 알아야합니다. 인증, 권한 부여, 감사 고전적인 실수는 사용자를 인증하는 것이지만 사용자가 일부 작업을 수행 할 권한이 있는지 확인하지 않기 때문에 사용자는 다른 사용자의 개인 사진을 볼 수 있습니다. 더 많은 사람들이 감사에 대해 잊어 버립니다. 보안 시스템에서 누가 언제 무엇을했는지 알 수 있으려면 보안 시스템이 필요합니다.

— 라파 두라
소스
1
모든 인증에 인증이 필요한 것은 아닙니다. "ABAC에서 ZBAC로" 는 인증이 필요없는 솔루션과 NBAC (인증 기반) 액세스 제어를 대조합니다. "IBAC, RBAC, ABAC 및 CBAC – 클레임 기반 액세스 제어는 모두 인증에 의존합니다.이 백서는 단순성을 위해 단일 솔루션으로 취급하고 ZBAC 아키텍처의 측면을 구현 한 버전을 무시합니다. 총칭하여 인증이라고합니다. "기반 액세스 제어 (NBAC)."
— Mike Samuel
4
  • 당신 (프로그래머)은 모든 부분을 보호해야하지만 공격자는 갑옷에서 하나의 꼬임을 찾는 데 성공해야합니다.
  • 보안은 "알 수없는 미지의"예입니다. 때로는 가능한 보안 결함이 무엇인지 알지 못할 수도 있습니다 (이후까지).
  • 버그와 보안 허점의 차이점은 공격자의 지능에 따라 다릅니다.
— 로리
소스
4

다음을 추가합니다.

  • 디지털 서명 및 디지털 인증서 작동 방식
  • 샌드 박싱이란?

다른 공격 경로의 작동 방식을 이해하십시오.

  • 네이티브 코드의 버퍼 오버플로 / 언더 플로 / 등
  • 사회 공학
  • DNS 스푸핑
  • 중간에있는 남성
  • CSRF / XSS 외
  • SQL 주입
  • 암호화 공격 (예 : DES와 같은 약한 암호화 알고리즘 활용)
  • 프로그램 / 프레임 워크 오류 (예 : github의 최신 보안 결함)

이 모든 것을 쉽게 구글로 할 수 있습니다. 이것은 당신에게 좋은 기초를 줄 것입니다. 웹앱 취약점을보고 싶다면 작동하는 웹앱 을 악용하는 방법을 보여주는 google gruyere 라는 프로젝트가 있습니다.

— Miguel Ping
소스
4

기업이나 자체 소프트웨어를 구축 할 때는 해커처럼 생각해야합니다. 해커도 모든 것에 대해 전문가가 아니지만 취약점을 발견하면 모든 정보를 수집하여 파헤 치기 시작합니다. 소프트웨어를 공격하고 공격을 막기 위해 다음과 같은 잘 알려진 규칙을 따라야합니다.

  • 항상 코드를 깨십시오 (치트 시트를 사용하고 자세한 정보는 구글을 사용하십시오).
  • 프로그래밍 분야의 보안 결함에 대한 업데이트.
  • 위에서 언급했듯이 어떤 유형의 사용자 또는 자동 입력도 절대 신뢰하지 않습니다.
  • 오픈 소스 응용 프로그램을 사용하십시오 (대부분의 보안 결함이 알려져 있고 해결되었습니다).

다음 링크에서 더 많은 보안 리소스를 찾을 수 있습니다.

애플리케이션 벤더 보안 플로우에 대한 자세한 정보는 Google에 문의하십시오.

— rahul_pratap
소스
3
  1. 왜 중요한가.
  2. 그것은 절충에 관한 것입니다.
  3. 암호화는 대체로 보안에 방해가됩니다.
— 리차드
소스
3

또한 모든 주요 공격 벡터 / 취약의 분류에 대해서는 OWASP Top 10 List 를 확인하십시오 .

이것들은 읽기에 매혹적입니다. 공격자처럼 생각하는 법을 배우면 자신의 코드를 작성할 때 생각할 내용을 교육 할 수 있습니다.

— Michael Kopinsky
소스
2

사용자의 비밀번호에 소금을 뿌리고 해시하십시오. 데이터베이스에 일반 텍스트로 저장하지 마십시오.

— 압둘
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.