タグ付けされた質問 「hacking」

10
ケントンプソンのコンパイラハックは依然として脅威ですか?
ケン・トンプソン・ハック(1984) Ken Thompsonは、1984年にコンパイラバイナリ(および* nixシステムのログインスクリプトのような他のコンパイル済みソフトウェア)を破壊する方法を概説しました。現代のコンパイルがこのセキュリティの欠陥に対処しているかどうか知りたいです。 簡単な説明: 2つの欠陥を含むようにコンパイラコードを書き直します。 独自のバイナリをコンパイルするとき、コンパイラはこれらの欠陥をコンパイルする必要があります 事前に選択された他のコード(ログイン関数)をコンパイルする場合、任意のバックドアをコンパイルする必要があります したがって、コンパイラは正常に動作します-ログインスクリプトなどをコンパイルするとき、セキュリティバックドアを作成でき、将来、それ自体の新しいバージョンをコンパイルするとき、以前の欠陥を保持します- そして、欠陥はコンパイラにのみ存在しますバイナリなので、検出が非常に困難です。 質問: 私はウェブ上でこれらに対する答えを見つけることができませんでした: これはジャストインタイムコンパイルとどのように関係しますか? * nixシステムでログインを処理するプログラムのような関数は、実行時にコンパイルされますか? これはまだ有効な脅威ですか、それとも1984年以降、これが重大な問題になるのを防ぐコンパイルのセキュリティの開発がありましたか? これはすべての言語に影響しますか? なぜ知りたいのですか? 宿題をしているときにこれに出くわしましたが、面白そうに思えましたが、これが現在の問題なのか、解決された問題なのかを具体的に理解する背景がありません。 参考資料 概要 いくつかのコード
156 linux  unix  compiler  hacking 

14
SQLインジェクション防止メカニズムがパラメーター化されたクエリを使用する方向に進化したのはなぜですか?
私の考えでは、SQLインジェクション攻撃は次の方法で防止できます。 入力を慎重にスクリーニング、フィルタリング、エンコードする(SQLへの挿入前) 使用して準備された文 /パラメータ化クエリを それぞれに長所と短所があると思いますが、なぜ#2が離陸し、インジェクション攻撃を防ぐための事実上の方法であると見なされるようになったのですか?単に安全でエラーが発生しにくいのですか、それとも他の要因がありましたか? 私が理解しているように、#1が適切に使用され、すべての警告が処理されれば、#2と同じくらい効果的です。 サニタイズ、フィルタリング、エンコード 私の側では、サニタイズ、フィルタリング、およびエンコードの意味が混乱していました。この場合、サニタイズとフィルタリングは入力データを変更または破棄する可能性があることを理解していますが、エンコードはデータをそのまま保持しますが、エンコードしますインジェクション攻撃を避けるために適切に。データをエスケープすることは、それをエンコードする方法と考えることができると信じています。 パラメータ化されたクエリとエンコーディングライブラリ parameterized queriesとの概念がencoding libraries相互に交換可能に扱われている答えがあります。私が間違っている場合は修正しますが、私はそれらが異なっているという印象を受けています。 私が理解しているのは、encoding librariesどんなに優れていても、SQL「プログラム」を変更する可能性は常にあるということです。 Parameterized queries 一方、SQLプログラムをRDBMSに送信すると、RDBMSはクエリを最適化し、クエリ実行プランを定義し、使用するインデックスを選択するなどして、RDBMS内の最後のステップとしてデータをプラグインします。自体。 エンコーディングライブラリ data -> (encoding library) | v SQL -> (SQL + encoded data) -> RDBMS (execution plan defined) -> execute statement パラメータ化されたクエリ data | v SQL -> RDBMS (query execution plan defined) -> …

5
JavaScriptを(ブラウザで)ハッキングするのはどれくらい簡単ですか?
私の質問はJavaScriptのセキュリティに関するものです。 BackboneやAngularJSのようなJavaScriptフレームワークを使用し、安全なエンドポイントが必要な認証システムを想像してください。サーバーは常に最後の単語を持ち、あなたが望むことをする権限があるかどうかをチェックするので、それは問題ではありません。 しかし、サーバーを使用せずに少しのセキュリティが必要な場合はどうでしょうか?それは可能ですか? たとえば、クライアント側のルーティングシステムがあり、ログインしたユーザーに対して具体的なルートを保護したいとします。したがって、保護されたルートへのアクセスを許可されているかどうかを確認するためにサーバーにpingを実行します。問題は、サーバーにpingを送信すると、応答を変数に保存するため、次回プライベートルートにアクセスしたときに、既にログインしている(サーバーにpingを送信していない)かどうか、および応答でそれが行くかどうか。 ユーザーがその変数を変更してアクセスするのは簡単ですか? 私のセキュリティ(およびJavaScript)の知識はあまり良くありません。しかし、変数がグローバルスコープ内になく、ゲッターのみを持ちセッターを持たないモジュールパターンのプライベート部分にある場合、その場合でも、ハッキングできますか?

10
競争で開発に「lingua obscura」を使用している場合(なぜ)心配する必要がありますか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 私はポール・グラハムのエッセイ-Beating The Averages(2003)を読んでいたのですが、彼が言わなければならないことは次のとおりです。 職務記述書のITフレーバーが多ければ多いほど、会社の危険性は低くなります。最も安全な種類は、Oracleの経験を必要とする種類でした。それらを心配する必要はありませんでした。また、彼らがC ++またはJava開発者を望んでいると言っても安全でした。彼らがPerlやPythonのプログラマーを望んでいたなら、それは少し恐ろしいことでしょう-少なくとも技術的な側面が本物のハッカーによって運営されている会社のように聞こえ始めています さて、これは時代遅れのエッセイです。ただし、一般的ではない言語(C / C ++ / Java、C#)を使用することが「危険性が低い」ことを確認できません。組織のプログラマーが開発言語に非常に精通している場合、彼らはまともなペースでコードを作成するのに等しく熟練する必要があります。実際、一般的でない言語を使用しても、長期的にはあまり多くのプログラマーが利用できないので、メンテナンス/拡張の問題に直面することはありませんか? Quick-n-Dirtyシステムを作成する場合、一部の言語では他の言語よりも比較的早く離陸できることに同意します。しかし、ポール・グラハムのエッセイ/コメントは2012年以降に意味をなしますか?スタートアップが開発に典型的なIT言語を使用する場合、競争の心配を減らす必要があるのはなぜですか? 言語自体がどのように違いをもたらすのか、私は理解できません。私見では、重要なのは開発者の経験であり、フレームワークを利用できるので、特定の言語でコーディングするだけでなく、DRY(繰り返しはしない)です。 私が見逃しているのは何ですか?スタートアップがIT風味のない言語を選択した方がよいということを意味しますか(開発者が非常に熟練している場合でも)。この主張の背後にある(プログラミング)経済/市場力とは何ですか? PS:「lingua obscura」は誰かの気持ちを傷つけることを意図したものではありません:)

7
すべてのセキュリティの脅威はソフトウェアのバグによって引き起こされていますか?
私が聞いたほとんどのセキュリティの脅威は、ソフトウェアのバグが原因で発生しました(たとえば、すべての入力が適切に健全性チェックされていない、スタックオーバーフローなど)。ソーシャルハッキングをすべて除外すると、すべてのセキュリティ上の脅威はバグによるものですか?言い換えると、バグがなければ、セキュリティ上の脅威はありませんか(再び、パスワードの開示などの人間の過失を除く)。または、バグが原因ではない方法でシステムを悪用できますか?
13 security  bug  hacking 

5
ソフトウェアの脆弱性に対する攻撃/ツールのソフトウェアライフサイクルの固有の側面は何ですか?
私の地元の大学には、約20人の学生からなる小さな学生向けコンピューティングクラブがあります。クラブには、モバイル開発、ロボット工学、ゲーム開発、ハッキング/セキュリティなど、特定の分野に重点を置いた小さなチームがいくつかあります。 ユーザーストーリー、タスクの複雑さの見積もり、バージョン管理と自動ビルド/テストの継続的な統合など、いくつかのチームにいくつかの基本的なアジャイル開発コンセプトを紹介しています。 ウォーターフォール、スパイラル、RUP、アジャイルなど、いくつかの基本的な開発ライフサイクルに精通していますが、セキュリティをハッキング/侵害するためのソフトウェア開発ライフサイクルのようなものがあるのだろうかと思っています。確かに、ハッカーはコンピュータコードを書いていますが、そのコードのライフサイクルは何ですか?いったん違反が発見されてパッチが適用されると、その違反を悪用したコードは役に立たなくなるので、彼らがメンテナンスにあまり関心を持つことはないと思います。 ライフサイクルは次のようになると思います: セキュリティのギャップを見つける セキュリティのギャップを悪用する ペイロードの調達 ペイロードを利用する 製品の目的がセキュリティ違反である場合、ソフトウェアの開発ライフサイクルにはどのような違いがありますか(ある場合)?

6
ソースコードを秘密にしておくことが正当化されるのはどのような場合ですか?
私がフリーランサーとして働いていたとき、プロジェクトとその背後にある概念がいかに重要でなく、興味深くなく、独創的でなくても、顧客がプロジェクト(Webアプリケーションなど)のアイデアとソースコードを可能な限り保護する多くのケースに遭遇しました。 私はすでにアイデアを秘密にしておくことについて質問を投稿し、多くの素晴らしい回答を受け取りました。今、私の懸念は、ソースコードの秘密性についてです。 私の観察によると: 私のキャリアで取り組む必要があったコードベース、 自分のソースコードの一部を秘密にしておくという私自身の意欲、および: たとえば、人気のあるProgrammers.SE寄稿者であるMason WheelerによるSimon StuartへのOpen応答などのいくつかの記事、 私はソースコードが主にこれらの理由のために秘密にされていると結論づけます: 作者はそのような質の悪いコードを恥じているか、誰かがそのような質の悪いコードベースを見た場合、またはコードベースの質が低い場合に評判を失うことを恐れているので、それをオープンソース化するのに役立つものは誰にもありません。たとえ誰かが興味を持っても、彼はソリューションを実行することがほとんどできません(または、多くの場合、コンパイルさえできません)。 コードの一部が盗まれているため(ほとんどの場合、特定の状況での使用を制限するライセンスの対象となるオープンソースプロジェクトから)、 コードはあいまいさによるセキュリティに依存しており、作者はケルクホフスの原則を気にしていません。 製品は非常に壊れやすいため、コードを表示すると非常に害が生じます。これらのセキュリティリークのあるクローズドソースのアプリが初心者のハッカーに耐える場合、初心者のハッカーであっても、同じオープンソースのアプリで発生する可能性ははるかに小さくなります。コードを調べてすべての穴を発見するだけです。 私が何を話しているのかはっきりしない場合は、ここに例があります: if (credentials.password === 'masterPassword12345') { isLoggedIn = true currentUser = credentials.userName } else { authenticate(credentials) } 著者がソースコード(および彼自身のスキルと専門知識)を過大評価したためです。例:自家製の暗号化関連のアルゴリズム(誰もレビューしなかった)は、よく知られたアルゴリズムよりも優れていると信じています。 なぜなら、コードの背後にあるアイデアは素晴らしいものであり、盗まれるだろうと著者が考えているからです。 「それは十分に完全ではない」症候群のために。言い換えれば、開発者はコードが「十分」であればソースコードを公開してもかまいませんが、日々改善すべき点があるため、コードがリリースされることはありません。 これらすべての理由は、ソースコードの公開に反対している人々のかなり否定的なイメージを与えます。 ケルクホフスの原則に従う高品質のコードを公開しない正当なケースはありますか?

3
安全なアプリケーションを開発する方法を学ぶための最良の方法は何ですか?
私は自分のキャリアの中でコンピューターのセキュリティーについて学びたいと思っています。安全にプログラミングする方法を学ぶ最良の方法は何ですか? 教科書や教科の講義に加えて、「ハッキング」の方法を学ぶことは、学習する最良の方法の1つであるように思えます。私がこれを考える理由は、誰かに望まないことをさせないようにする方法を学ぶ最善の方法は、彼らができることを学ぶことだという考えです。 これが事実である場合、これは別の質問を提起します:倫理的な方法でハッキングすることをどのようにして学びますか?法律を破ったり、探求に危害を加えたりしたくはありません。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.