すべてのプログラマはセキュリティについて何を知っているべきですか？[閉まっている]

427

私はIT学生で、大学3年生です。これまで、コンピューターに関連する多くのテーマ（プログラミング、アルゴリズム、コンピューターアーキテクチャ、数学など）を研究してきました。

誰もがセキュリティについてすべてを学ぶことができないと確信していますが、すべてのプログラマーまたはIT学生がそれについて知っておくべき「最低限」の知識があり、私の質問はこの最低限の知識は何ですか？

電子書籍やコースなど、この道を始めるのに役立つ何かを提案できますか？

security 
— MH
ソース
6
— Thomas
118
ルール1：ユーザーの入力を信頼しない。それがあなたの祖母であっても
— Anthony Forloney
2
..andこのスレッドはまた、偉大な情報を持っている- stackoverflow.com/questions/72394/...
— Sripathiクリシュナン
私の質問は、プログラマーとその間違いについてだけでなく、ITとコンピューターサイエンスの学生についてもです
— Mohamad Alhamoud
1
エラーメッセージを確認します。ユーザーフレンドリになりたい場合でも、「このアカウントは存在しません」と「パスワードが無効です」の違いが危険な場合があります。
— Michael Mior

回答:

551

アプリケーションを安全にしたい場合に覚えておくべき原則：

  • 入力を信頼しないでください！
  • すべての信頼できないソースからの入力を検証する -ブラックリストではなくホワイトリストを使用する
  • 最初からセキュリティを計画する-それは最後に追加できるものではありません
  • シンプルに保つ-複雑さはセキュリティホールの可能性を高めます
  • あなたキープ攻撃面を最小限に
  • 安全に失敗することを確認してください
  • 多層防御を使用する
  • 最小特権の原則に従う
  • 脅威モデリングを使用する
  • 区画化 -システムがすべてではないか、まったくないか
  • 秘密を隠すことは難しい-そしてコードに隠された秘密は長い間秘密にされない
  • 独自の暗号を書かないでください
  • 暗号を使用しても、安全であるとは限りません（攻撃者はより弱いリンクを探します）
  • バッファオーバーフローとそれらからの保護方法に注意してください

アプリケーションを安全にするための優れた書籍や記事がオンラインでいくつかあります。

アプリケーションセキュリティのベストプラクティスについて開発者をトレーニングする

コードバッシング（有料）

セキュリティイノベーション（有料）

セキュリティコンパス（有料）

OWASP WebGoat（無料）

— bignum
ソース
+1「ソフトウェアを悪用する：コードを壊す方法」は素晴らしい本ですが、あなたがリンクしたスライドショーは恐ろしいものです。
— 2010年
7
ただし、残念ながら、最新のシステムで最小特権の原則をインスタンス化することはほとんど不可能です。たとえば、Linuxカーネル（私が現在使用しているソース）には、940万行を超えるCコードと400K行を超えるアセンブリが含まれており、これらはすべて無制限のコンテキストで実行されます。これらの数百万行の1つでの単純な誤算（おそらく意図的）は、システム全体を危険にさらします。安全なOS /言語/フレームワークの作成を実際に気にしている人がいないため、おそらく次の1、2世紀には解決策が現れるでしょう。
— L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ 2010
1
そのリストに「Webアプリケーションハッカーのハンドブック」を追加します。
— 上回る
34
「ユーザー入力を信頼しないでください！」を置き換えます。「決して入力を信頼しないでください！」他のソフトウェアからの入力はユーザー入力と同じように処理する必要があります。たとえば、Webサイトのロギングでは、ほとんどの人はUser-Agent /ブラウザーIDフィールドを「ユーザー入力」とは見なしませんが、たとえば、 SQLインジェクション。
— Peteris
2
@ L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳まあ、.NET上に構築されたMicrosoft Researchの実験的OS（特異点）があり、安全を第一の目標としていた（バッファオーバーフローはない、そうだ！）。プロセスメモリの共有やコードの自己変更はありません。デバイスドライバーでさえ、.NETのソフトウェア分離プロセスにすぎません。かなり興味深い概念ですが、これを人々にプッシュするのは非常に困難です（最も重要なのは、既存のソフトウェアやドライバーとの下位互換性をほとんど実現できないことです。Linuxの最初の10年間のようなものです：D）。
— Luaan 2014
102

プログラマのためのセキュリティのルール＃1：自分でロールバックしないでください

あなた自身がセキュリティの専門家や暗号技術者でない限り、常に適切に設計され、十分にテストされ、成熟したセキュリティプラットフォーム、フレームワーク、またはライブラリを使用して作業を行ってください。これらのことは、専門家やハッカーによって同様に何年にもわたって考えられ、パッチが当てられ、更新され、調査されてきました。あなたはそれらの利点を手に入れたいのであって、車輪を再発明しようと試みることによってそれらを却下するのではありません。

だからといって、セキュリティについて何も学ぶ必要がないというわけではありません。自分が何をしているのかを理解し、ツールを正しく使用していることを確認するのに十分な知識が必要です。ただし、独自の暗号化アルゴリズム、認証システム、入力サニタイザーなどを書き始めようとしている場合は、停止し、一歩下がって、ルール＃1を覚えておいてください。

— タイラー・マクヘンリー
ソース
10
これは私の考えでは悪いルールです。資産への本当の関心ではなく、選択したプラットフォームのおかげで、基本的にターゲットにすることができます。サードパーティのプラットフォームに見られるすべてのセキュリティホールと、それを使用しているという理由だけで即座に脆弱になるすべての製品について考えてみてください。私は自分のセキュリティをサードパーティにすぐに信頼することはできません。
— Fosco、2012年
9
これはCryptoの良いルールだと思います。独自の暗号化を導入することは災害のレシピです。ただし、Foscoが指摘するように、独自のブログエンジンをロールする方が安全な場合があります。自分でロールする場合、WordPressのインストールで処理する必要がある自動化された攻撃に見舞われる可能性は低くなります。
— James P McGrath、2012年
5
暗号に関しては、このルールは完全に正しいです。あなた自身の暗号、ピリオドを書かないでください。サードパーティのプラットフォームを使用する場合は、状況によって異なります。一部のプラットフォームは本質的に安全性が高く、一部のプラットフォームは本質的に安全性が低く、ほとんどのプラットフォームはおそらくいくつかのセキュリティ機能だけでなく、いくつかの既知の攻撃ベクトルも提供します。githubにセキュリティホールを引き起こした最近のRailsの脆弱性を取り上げます。間違いなくRailsは多くの多くのセキュリティ機能を提供しますが、安全でないデフォルトのいくつかの強力な機能も備えています。
— Michael Kopinsky
7
暗号化に関しては、自分でロールバックしないでください。ただし、使用しているものを理解してください。2つのメッセージに対してRC4に同じ暗号化キーを使用することがなぜ恐ろしい考えなのかが理解できない場合は、たとえば、ストリーム暗号を使用する前によく読んでください。
— Christopher Creutzig、2012年
3
HeartBleedバグの後でさえ、これは良いルールであることが明らかです。カスタムプロジェクトまたはプロプライエタリプロジェクトでヒートブリードのようなバグを見つけるのがどれほど大変だったか想像してみてください。自分で自分を転がすと、あなたは単に覆い隠されたところに隠れているだけで、どのバグが悪用される可能性があるのか​​わかりません。
— Sqeaky
71

すべてのプログラマーは、エクスプロイトコードの記述方法を知っている必要があります。

システムがどのように悪用されるかを知らなければ、誤って脆弱性を阻止していることになります。パッチのテスト方法を知らない限り、コードにパッチを当てる方法を知っていても、まったく意味がありません。セキュリティは単なる思考実験の集まりではなく、科学的であり、実験をテストする必要があります。

— ルーク
ソース
10
これはまったく必要ないと主張します。原則に忠実に従ってください。攻撃者があらゆる種類のメモリ破損を引き起こす可能性がある場合は、自分が所有していると考えてください。実際に（機能する）エクスプロイトを作成する詳細に入る必要はありません。
— newgre 2012年
6
@newgreのすべての脆弱性がバッファオーバーフローであるとは限りません。Common Weakness Enumerationシステムによってカバーされる数千の脆弱性があります。プログラマーは攻撃者の心を理解する必要があります。
— ルーク
1
私はそれらすべてがバッファオーバーフローであるとは限らないことを知っていますが、通常「エクスプロイト」と呼ばれるものはなんらかのメモリ破損に基づいています：バッファオーバーフロー、ダブルフリー、ヒープオーバーフロー、整数関連オーバーフロー、フォーマット文字列もちろん、ロジックのバグなど、他にもありますが、そもそもこの回答のトピックではありませんでした。
— newgre
5
@newgreこれはエクスプロイトの一種ですが、今日では、メモリ破損の問題よりもWebアプリケーションの欠陥を利用するために、より多くのエクスプロイトが作成されています。エクスプロイトは、SQLインジェクション、ローカルファイルインクルード、CSRF、XSSを利用して作成されていますが、これらは一般的な問題です。（出典：exploit-db.com）
— ルーク
1
私もそれに同意します。もしあなたがエクスプロイトを書くことができれば、最大でハッカーの心に何ができるかについて理解することができます！
— linuxeasy 2012年
42

セキュリティはプロセスであり、製品ではありません。

多くの人はこの明らかな事実を忘れているようです。

— Ericteubert
ソース
23

CWE / SANS TOP 25 Most Dangerous Programming Errorsを確認することをお勧めします。2010年に更新され、将来の定期的な更新が約束されています。2009年改訂版も同様に利用可能です。

http://cwe.mitre.org/top25/index.htmlから

2010 CWE / SANS Top 25 Most Dangerous Programming Errorsは、深刻なソフトウェアの脆弱性につながる可能性のある、最も広範囲で重大なプログラミングエラーのリストです。彼らはしばしば見つけやすく、悪用しやすいです。攻撃者がソフトウェアを完全に乗っ取ったり、データを盗んだり、ソフトウェアがまったく機能しなくなったりすることがよくあるため、危険です。

トップ25リストは、ソフトウェアが出荷される前に発生する一般的な間違いを特定して回避することにより、プログラマーがソフトウェア業界を悩ます種類の脆弱性を防止するのに役立つ教育と認識のためのツールです。ソフトウェアのお客様は、同じリストを使用して、より安全なソフトウェアを要求することができます。ソフトウェアセキュリティの研究者は、トップ25を使用して、既知のすべてのセキュリティの弱点の狭いながらも重要なサブセットに焦点を当てることができます。最後に、ソフトウェアマネージャーとCIOは、ソフトウェアを保護するための取り組みの進捗状況を示す指標として、トップ25リストを使用できます。

— jschmier
ソース
1
そのリストの上位4つのエラー（およびその他のエラーも）はすべて同じエラーであり、入力を信頼していることに注意してください。
— クリス・ドッド
13

コンピュータネットワークとセキュリティの MITコースがよいスターターコースかもしれません。私が提案したいのは、プライバシーを忘れないことです。プライバシーは、ある意味では、セキュリティの基盤であり、セキュリティに関する技術コースではカバーされないことがよくあります。プライバシーと倫理に関する法律のこのコースでは、インターネットに関連するプライバシーに関する資料が見つかるかもしれません。

— tvanfosson
ソース
MITコースのリンクが機能しない
— AntonioCS
1
リンクが修正されました（現時点では）。ありがとう。
— tvanfosson
8

フレームワークとAPIにおける安全なデフォルトの重要性：

  • 多くの初期のWebフレームワークは、デフォルトでテンプレートのHTMLをエスケープせず、このためXSSの問題がありました
  • 初期のWebフレームワークの多くは、SQLインジェクションバグの多くにつながるパラメーター化されたクエリを作成するよりも、SQLを連結することを容易にしました。
  • Erlangの一部のバージョン（R13Bなど）はデフォルトでSSLピア証明書を検証せず、SSL MITM攻撃の影響を受けやすい多くのerlangコードが存在する可能性があります
  • JavaのXSLTトランスフォーマーは、デフォルトで任意のJavaコードの実行を許可します。これにより、多くの深刻なセキュリティバグが発生しています。
  • デフォルトでは、JavaのXML解析APIにより、解析されたドキュメントがファイルシステム上の任意のファイルを読み取ることができます。もっと楽しく ：）
— ベンマーフィー
ソース
5

3つのAについて知っておく必要があります。認証、承認、監査。古典的な間違いは、ユーザーを認証することですが、ユーザーが何らかのアクションを実行する権限があるかどうかをチェックしないため、ユーザーは他のユーザーのプライベート写真を見る可能性があります。安全なシステムでは、誰がいつ何をしたかを知ることができるようにするために、多くの人々が監査について忘れています。

— ラパドゥーラ
ソース
1
すべての承認に認証が必要なわけではありません。 「ABACからZBACへ」は、NBAC（認証ベース）アクセス制御と、認証を必要としないソリューションを対比しています。「IBAC、RBAC、ABAC、さらにはCBAC –クレームベースのアクセス制御はすべて認証に依存しています...簡単にするために、このホワイトペーパーではこれらを単一のソリューションとして扱い、ZBACアーキテクチャの側面を実装したバージョンを無視します。これらはまとめてautheNticationと呼ばれますベースのアクセス制御（NBAC）。」
— マイクサミュエル
4
  • あなた（プログラマー）はすべての部分を保護する必要があることを覚えておいてください。ただし、攻撃者はあなたの鎧の1つのキンクを見つけることに成功するだけです。
  • セキュリティは「未知の未知数」の一例です。時々、起こり得るセキュリティの欠陥が何であるかを知らない場合があります（その後まで）。
  • バグとセキュリティホールの違いは、攻撃者の知能に依存します。
— ロリー
ソース
4

以下を追加します。

  • デジタル署名とデジタル証明書の仕組み
  • サンドボックスとは

さまざまな攻撃ベクトルがどのように機能するかを理解します。

  • ネイティブコードでのバッファオーバーフロー/アンダーフローなど
  • ソーシャルエンジニアリング
  • DNSスプーフィング
  • 真ん中の男
  • CSRF / XSS他
  • SQLインジェクション
  • 暗号攻撃（例：DESなどの弱い暗号アルゴリズムの悪用）
  • プログラム/フレームワークエラー（例：githubの最新のセキュリティ欠陥）

これらすべてを簡単にグーグルできます。これはあなたに良い基盤を与えるでしょう。Webアプリの脆弱性を確認したい場合は、機能しているWebアプリを悪用する方法を示すgoogle gruyereというプロジェクトがあります。

— Miguel Ping
ソース
4

企業や独自のソフトウェアを構築しているときは、ハッカーのように考える必要があります。ハッカーもすべてのことを熟知しているわけではないので、脆弱性を見つけると、すべての情報を収集することで、ハッカーを掘り下げます。物事、そして最後に私たちのソフトウェアへの攻撃です。そのような攻撃を防ぐために、私たちは次のようなよく知られたルールに従う必要があります：

  • 常にコードを破るようにしてください（詳細については、チートシートを使用し、Googleで確認してください）。
  • あなたのプログラミング分野のセキュリティ欠陥のために更新されます。
  • 上記のように、いかなる種類のユーザーまたは自動入力を信頼することはありません。
  • オープンソースアプリケーションを使用します（ほとんどのセキュリティ上の欠陥は既知であり、解決されています）。

次のリンクでより多くのセキュリティリソースを見つけることができます。

アプリケーションベンダーのセキュリティフローの詳細については、Googleをご覧ください。

— rahul_pratap
ソース
3
  1. なぜ重要なのですか。
  2. それはすべてトレードオフについてです。
  3. 暗号化は、主にセキュリティを妨げるものです。
— リチャード
ソース
3

セキュリティに関する一般的な情報については、Bruce Schneierを読むことを強くお勧めします。彼はウェブサイト、彼の暗号文のニュースレター、いくつかの本を持っています、そしてたくさんのインタビューをしました。

また、ソーシャルエンジニアリング（およびKevin Mitnick）にも慣れます。

現実の世界でセキュリティがどのように機能するかについての優れた（そしてかなり面白い）本として、クリフストールの優れた（少々古くはありますが）「The Cuckoo's Egg」をお勧めします。

— ダンエスパルザ
ソース
3

また、すべての主要な攻撃ベクトル/脆弱性の分類については、OWASPトップ10リストを必ず確認してください。

これらのことを読むのは魅力的です。攻撃者のように考えることを学ぶことは、あなたがあなた自身のコードを書いているときに何を考えるべきかについてあなたを訓練するでしょう。

— Michael Kopinsky
ソース
2

ユーザーのパスワードをソルトしてハッシュします。それらをプレーンテキストでデータベースに保存しないでください。

— アブドル
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.