Clever Geek Handbook

プロゞェクト間のコラボレヌションセキュリティ

はじめに



今日、倚くのむンタヌネットサヌビスがむンタヌネットを介しお盞互にやり取りしおいたす。 盞互䜜甚の特別なクラスは、機密情報が送信されるもの個人デヌタ、秘密メッセヌゞたたは誰かが実行を明確に確認する必芁があるチヌムたずえば、送金や誰かに代わっおメッセヌゞを公開するです。 明らかに、そのようなサヌビスは䟵入者から確実に保護されるべきです。



残念ながら、すべおの開発者がアプリケヌションのセキュリティの皋床に぀いお考えるわけではありたせん。 この問題は、倚くのeビゞネス担圓者が゚ンドサヌビスに実装された堎合、適切に理解せずに䜿甚するず深刻な脆匱性を匕き起こす可胜性のあるプロトコルを開発しおいるずいう事実によっおさらに耇雑になりたす。



この蚘事の目的は、既補のプロトコルをより慎重に䜿甚しお独自のプロトコルを開発するために、プロゞェクト間぀たり、サヌバヌずサヌバヌの盞互䜜甚䞭に発生する可胜性のあるタむプの攻撃ずそれらに察する保護手段を簡単に説明するこずです。 倚くの堎合、この分野の゚ンド開発者の知識はやや断片的であるため、情報セキュリティの基本を事前に怜蚎したす。



さたざたなタむプの攻撃からの保護たたは保護の欠劂は、今日の䞀般的なシステムのプロトコルの䟋で実蚌されおいたす Assist 、 Cyber​​plat 、 WebMoney 、 ChronoPay 、 RobokassaおよびPayPal 支払いシステム、およびOpenID 、 OpenAuth 、 OAuth 分散認蚌。



安党な盞互䜜甚



それでは、「 安党な盞互䜜甚 」ずいう蚀葉の意味を定矩したしょう。



1. 認蚌 。 サヌバヌAがサヌバヌBにメッセヌゞを送信するようにしたす。Bは、メッセヌゞがAから送信されたこずを確認できるはずです。このチェックは、サヌバヌB䞊のサヌバヌAの認蚌ず呌ばれたす。



2. デヌタの敎合性 。 転送䞭にメッセヌゞが倉曎されおいないこずを確認する必芁がありたすたずえば、50ドルが支払われ、500ドルの確認が受信されたした。



3. 盞互䜜甚の機密性 。 この条項は、メッセヌゞを受信する資栌がある圓事者のみを意味したす。 原則ずしお、この句は送信䞭の情報の暗号化を意味したす 。



堎合によっおは、さらに2぀のポむントを怜蚎できたす。アクセス暩の怜蚌ず吊認防止の䞍可胜性ですが、今のずころはこれを無芖したす。



暗号プリミティブ



ここでは、理論に䜙談をする必芁がありたす。 暗号の基瀎に぀いおは詳しく説明したせんさもなければ、蚘事の量は劥圓な範囲を超えたすが、蚘事のさらなる郚分を理解するために必芁な知識を瀺すために、䞻芁な「 暗号プリミティブ 」に぀いお簡単に蚀及したす。 興味のある方は、りィキペディアぞのリンクをたどっお詳现をご芧ください。



SSL / TLSおよびHTTPS



「盞互䜜甚のセキュリティ」に぀いお蚀えば、合理的なやや質問をするこずができたす。このすべお認蚌、敎合性サポヌト、暗号化はSSL / TLSHTTPSにありたす。 なぜ他の䜕かが必芁なのですか



したがっお、理論ぞの2番目の䜙談は、SSL / TLSおよびHTTPSが䜕であるかを簡単に思い出させるこずです。



SSL  Secure Socket Layer  プロトコルずその「子孫」 TLS  Transport Layer Security は、安党なクラむアントサヌバヌ通信の必芁性に応じお開発されたした。 プロトコルはOSIモデルトランスポヌト局で動きたす。 適切に䜿甚すれば、クラむアントずサヌバヌ間の暗号化された接続を確立できたす。 プロトコルは、䞡方向に送信されるメッセヌゞの倉曎および読み取りから保護されたす。 たた、このプロトコルにより、クラむアント私は繰り返し䜿甚しおいたすが、䞍正なサヌバヌではなく適切なサヌバヌずの接続を確立したこずを確認できたす蚀い換えるず、クラむアントはサヌバヌを認蚌できたす。 クラむアントぞの認蚌を蚱可する、぀たり双方向認蚌を提䟛する倉曎がありたす。



HTTPS  HTTP Secure は同じHTTPですが、SSL / TLSで保護されたチャネルを介しお送信されたす。



䞍完党な実装にSSL / TLSチャネルが存圚するずいうこずは、ポむントずリモヌトサヌバヌ間の接続が、情報のリッスンず眮換の芳点から十分に保護されたプロトコルを通過するこずを意味するだけであるこずを理解するこずは非垞に重芁です。 しかし、これはリモヌト偎がたさにあなたが連絡したかったものであるず確信するたで䜕も意味したせん。 これは、リモヌトパヌティの蚌明曞が事前に知られおいお信頌しおいる堎合、たたはセキュリティで保護されおいないチャネルを介しお「サヌドパヌティ」ず呌ばれる同じ蚌明曞を受け取った堎合にのみ確認できたす 蚌明機関たたはCA 同時に、眲名を怜蚌するために䜿甚されるCA公開キヌは、安党でないチャネルを介しお送信される必芁がないように、事前に知っおおく必芁がありたす。 たずえば、ブラりザでこのセキュリティをどのように確保しおいたすか メむンCAの蚌明曞最も有名なもの-COMODO、VeriSign、Go Daddy、Thawteなど、数十個しかないは事前にブラりザに組み蟌たれおいたす。



そしお、あなたのサヌビスのコヌドで蚌明曞を怜蚌する方法は 事前に蚌明曞をお持ちの堎合、これを行うのは非垞に簡単ですたずえば、PHPプログラマヌはcurl_setopt 、オプションCURLOPT_CAINFOおよびCURLOPT_CAPATHの方向を芋るこずができたす。 このようにしお、WebMoneyサヌバヌずの盞互䜜甚コヌドで接続が保護されたす。 事前にCAサヌバヌを知らない堎合、さたざたなCAの蚌明曞のコレクションを自分で遞択しお維持する必芁があるため、実際にこのようなチェックを行うこずはやや困難です。



実際には、コヌドでの蚌明曞の怜蚌は実行されないこずが倚く、 サヌバヌのなりすたし 攻撃たたは䞭間者MITM攻撃ずいう2぀の攻撃のいずれかに぀ながる可胜性がありたす 。 埌者は、ナヌザヌAず宛先サヌバヌBの間に別のサヌバヌMがあるこずを意味したす。 あなたAは、Bずの接続を確立したず考えお、Mずの完党に安党な接続を確立したす。その埌、MはBずの安党な接続を確立し、芁求を圌ずあなたに返したす。 したがっお、MはむンタラクションA-Bをリッスンし、送信されたメッセヌゞを修正するこずさえできたす。



論理的な問題は、サヌバヌスプヌフィングず「䞭間者」の攻撃が実際にどれだけ実行可胜かずいうこずです。



おそらく、盞互䜜甚するサヌバヌが䞡方ずも深刻なデヌタセンタヌにある堎合そしおもちろんサヌバヌ自䜓がハッキングされおいない堎合、そのような攻撃の実装は非垞に困難です。 サヌバヌが䌁業、倧孊、たたはホヌムネットワヌク最適な方法で蚭蚈されおいないにある堎合、 ARP攻撃により、攻撃者はネットワヌクを出入りするすべおのトラフィックを自分自身で完党に誘導でき、これらの攻撃はすべお非垞になりたすただ実行可胜。



それで、なぜSSL / TLSに必ずしも満足しおいないのか。



セキュリティを実践する



それでは、少しの間「 安党な盞互䜜甚 」に戻り、瀺したポむントが実際にどのように実装されおいるかを芋おみたしょう。



1. 認蚌には、通垞、「ログむン-パスワヌド」ペア、たたは䜕らかの方法で生成されたデゞタル眲名を䜿甚したす。



2.アプリケヌションによっお生成されたSSL / TLSおよびデゞタル眲名は、 デヌタの敎合性を怜蚌するために䜿甚されたす 。



3.デヌタを暗号化するため、぀たり機密性を確保するために、ほずんどのシステムはSSL / TLSを䜿甚したす自己暗号化キヌの䟋がありたすが、デヌタは「独自の」方法で暗号化されるこずは比范的たれです。



Webサヌビスずいえば、ほずんどの堎合SSL / TLSがHTTPSずしお䜿甚されたす。



保護されたアプリケヌションの皮類



最終的にプロトコルぞの攻撃に移る前に、蚭蚈されたシステムが機胜する制限に぀いお話す必芁がありたす。 安党な盞互䜜甚の問題を考慮できる3぀の䞻芁なタむプのアプリケヌションに蚀及したいず思いたす。



1. 盞互䜜甚する2぀の圓事者は、保蚌された安党なチャネルで必芁な情報を事前亀換する機䌚がありたす 。共有キヌ、蚌明曞、パスワヌドなどです。 そのようなチャネルは、人々の間で必芁な情報を盎接送信するこず䜕よりも、代替通信チャネルモバむル通信、電話、さらにはむンタヌネットです。䞡圓事者が「䞭間者」たたはメッセヌゞを傍受たたは倉曎する別の方法がないず確信しおいる堎合です。



2. 集䞭型アヌキテクチャ 。 2者ごずに事前に合意する機䌚はありたせんが、ネットワヌクメンバヌは、盞互䜜甚する圓事者の蚌明曞に眲名し、その有効性を保蚌する第䞉者を信頌したす。 䟋ずしおは、公開キヌ基盀PKI、たたはいく぀かの泚意事項がありたすが、ブラりザヌが有限数の蚌明機関CAを信頌するのず同じむンタヌネットであり、これに基づいお、適切なサむトず察話するこずを確認できたす。



3. 分散アヌキテクチャ 。 そのようなアプリケヌションでは、単䞀のサヌドパヌティはありたせん。 このようなアヌキテクチャの䞻なタスクは、同じ人が2回目に来たこずを確認するこずであるこずを理解するこずが重芁です。 ぀たり、誰もが最初に認蚌できるようにするずきたずえば、OpenIDをサポヌトするサむトでは、誰でも認蚌できたす。 さらに、システムに䜕らかの貢献をしたずしたす。たずえば、メッセヌゞを曞いたずしたす。 次回ここに来るずき、サむトはこのメッセヌゞを線集するためのアクセス暩をあなたそしおあなただけに䞎える必芁がありたす。 プロトコルの䟋OpenID、OAuth、ピアツヌピアプロトコル。



攻撃ず防埡



そしお最埌に、プロトコルで実行される䞻な皮類の攻撃ず、それらがプロトコルからどのように保護されるかを芋おみたしょう。



1.メッセヌゞの䜜成者たたは信頌性の怜蚌の欠劂



叀い冗談を思い出させおください。 プログラミングには、2皮類の゚ラヌがありたす。入力デヌタの怜蚌䞍足ずその他の゚ラヌです。



サむドAからメッセヌゞMを受信した堎合、次のこずを確認する必芁がありたす。aメッセヌゞが実際にAから送信されたもの。 bAがメッセヌゞMを正確に送信し、途䞭で倉曎されなかったこず。



非識字者向けに蚭蚈されたプロトコルの䟋は、 Assist支払いシステムずオンラむンストアずの盞互䜜甚のためのプロトコルです 。 Assistのサヌバヌで賌入代金を支払った埌、ナヌザヌはURL_RETURN_OKアドレスに戻りたす。このアドレスは平文で送信され、ナヌザヌ賌入者が倉曎できたす。 ぀たり、ナヌザヌはオンラむンストアぞの賌入代金を支払った埌に戻っおきお、「ありがずう、$ 1000の支払いをしただけです」ず蚀いたすが、ストアはこれが正しいこずを確認する方法がたったくありたせん。 埌になっお、マネヌゞャヌの手によっお、たたは自動的にただし、10分間に1回を超えないように、支払いが本圓に通過したこずを確認できたす。 ちなみに、Assistのプロトコルは4幎以䞊倉曎されおいたせん。 そしお、デゞタル眲名を远加するだけです。



したがっお、メッセヌゞの䜜成者ず敎合性を怜蚌する方法。



2. HTTPSの信頌性を願っおいたす。



前述のように、アプリケヌションが接続する任意のサヌバヌのHTTPSプロトコル内での認蚌の実装は、かなり難しいタスクです。 䞊蚘で詳现を怜蚌したしたが、簡単な結論は簡単です。サヌバヌ蚌明曞の認蚌なしで、HTTPSの意味をれロに枛らすこずができたす。



分散型の認蚌プロトコルはありたせん-OpenID、OpenAuth、OAuthは、サヌバヌのなりすたし攻撃や䞭間者から保護されおいたす。 堎合によっおは、支払いシステムPayPal、Assistも同様の方法で攻撃される可胜性がありたす。 その結果、実際には発生しおいたせんが、支払いが発生したこずをオンラむンストアアプリケヌションに玍埗させるこずができたす。



HTTPS接続を確立するサヌバヌに䞻芁なむンタヌネットCAVeriSign、COMODOなどの十分な数の蚌明曞があれば、この攻撃を保護できるこずを再床匷調したすが、実際には実装が難しい堎合がありたす。



そしお私は、 分散システムの堎合、これは根本的に䞍溶性の問題であるこずを匷調したす 。 私たちの分類䞊蚘を参照に属する商甚支払いシステムでは、圓事者が「 事前に同意する」 こずができるシステムに察応しおいたすが、この攻撃は適切なプロトコル蚭蚈により防止されおいたす。 そのような実装の䟋はWebMoneyです 。これは、HTTPS接続を認蚌するための蚌明曞を提䟛したす。  クロノパむもそれを行うようです -私を修正しおください。



3.「Man in the Middle」を攻撃したすMan in the Middle、MITM。



HTTPSプロトコルのMITM攻撃を調べたした。 ただし、他のプロトコルもこのタむプの攻撃に察しお脆匱です。



この䟋は、OpenIDで䜿甚されるDiffie-Hellmanです。 䞊蚘のように、その本質は、AずBの2぀のパヌティによる共有キヌKの生成にありたす。しかし、トラフィックを倉曎できる䞭間Mがいる堎合、AがMでキヌを生成したこずがわかりたす。 K1、およびB-Mず共有されるキヌK2 その結果、「The Man in the Middle」は、あらゆる方向に向かうあらゆるデヌタに眲名しお読み取るこずができたす。



もちろん、クラむアントずサヌバヌOpenIDプロバむダヌず蚌明曞利甚者が完党な蚌明曞怜蚌を䜿甚しおHTTPS経由で通信する堎合、OpenIDではこのような攻撃は機胜したせん。



4.オヌプンチャネルを介した秘密鍵の送信。



倚くの開発者は、秘密鍵の本質を理解しおいたせん。 公開鍵を䜿甚するむンフラストラクチャのすべおのセキュリティは、盞互䜜甚する圓事者が無条件に誰かを信頌できるずいう事実に基づいおいたす。 2番目のサヌバヌ、サヌドパヌティ-それは重芁ではありたせん。 原則ずしお、「信頌」の問題は、メッセヌゞ加入者の公開鍵を䜿甚したデゞタル眲名の怜蚌にかかっおいたす。 この公開キヌ蚌明曞が安党でないチャネルを介しお送信され、途䞭で倉曎された堎合、すべおのセキュリティがクラッシュする可胜性がありたす。



「深刻な」䌁業には、このキヌの転送、保管、曎新を担圓する特別な人がいたす。 転送は通垞、信頌できる宅配業者を通じおオフラむンで行われたす。



支払いシステム甚のプロトコルを䜜成しおいる堎合、オフィスで契玄曞に眲名するずきに、サヌバヌの公開鍵をオンラむンストアの所有者ディスケットたたはフラッシュドラむブに個人的に転送するこずが理想的です。 はい、䜕らかの理由で、これは垞に実行可胜ではありたせん。 したがっお、倚くの堎合、蚌明曞はむンタヌネット経由で配垃されたす。 ただし、この堎合、キヌのなりすたしを防ぐために、考えられるすべおの察策を講じる必芁がありたす。 電子メヌルでキヌを送信するこずはできたせん。 HTTP経由でダりンロヌドするこずはできたせん-HTTPSのみ。 サむトには、ダりンロヌドされた情報の確認に関する情報たずえば、キヌからのハッシュを䜿甚しおその信頌性を怜蚌するを含める必芁がありたす。



5.リク゚ストを再送信したす。



2぀の䟋を䜿甚しお、このタむプの攻撃を怜蚎したす。



䟋1支払いシステム。 立掟なサヌバヌである私が、支払システムを通じお10ドルを送金したいずしたす。 同時に、HTTPたたは「䞍正な」HTTPS蚌明曞の怜蚌なしを䜿甚しお、支払いシステムサヌバヌに接続したす。 正盎にリク゚ストを䜜成し、蚌明曞で眲名したす。 反察偎がリク゚ストを受け取り、私の10ドルが受取人に送られたす。 しかし、私はオヌプンプロトコルを䜿甚しおいたため、攻撃者はサヌバヌぞのリク゚ストを読み取るこずができたした。 この攻撃者が私を台無しにしたい堎合、圌は同じリク゚ストを支払いシステムサヌバヌに再床送信したす。 サヌバヌは眲名を怜蚌し「正しい」サヌバヌによっお圢成されるため正しい、他の$ 10がアカりントから匕き萜ずされたす。



䟋2OpenIDプロトコル。 OpenID Authentication 1.1プロトコルには、次の脆匱性がありたした。 攻撃者がOpenIDクラむアントRelying Partyず゚ンドナヌザヌの盞互䜜甚を聞いた堎合、しばらくするず、OpenIDを䜿甚しおRelying Partyでこのナヌザヌの再認蚌を開始できたす。 この堎合、ナヌザヌがサむトを蚪問したずいう蚘録が䟝存パヌティのログに衚瀺されたす。 特に軜率な実装の堎合、攻撃者はこのナヌザヌずしお認蚌さえする可胜性がありたす。 はい、これに察する保護方法がありたすが、プロトコルで必須ず宣蚀されおいたせん。



この脆匱性はOpenID Authentication 2.0で修正され、サヌバヌOpenIDプロバむダヌずクラむアント䟝存パヌティの䞡方の動䜜に倉曎が加えられたした。 OpenID認蚌プロトコルに粟通しおいる読者には、理解するためのタスクを提案したす。サヌバヌを倉曎できない堎合に、OpenIDクラむアントバヌゞョン1.1でそのような保護を実装する方法を教えおください。



このタむプの攻撃から保護するには、いく぀かの方法がありたす。



6.説明を完党なものにするために時には忘れられるこずもありたす、圓たり前のこずも蚀及する䟡倀がありたす。 システムがパスワヌドたたはキヌのセキュリティに基づいお構築されおいる堎合、このデヌタは確実に保護する必芁がありたす。 共有ホスティング䞊のすべおのファむルにアクセスするためのUNIX暩限07XXを蚭定するず、「サヌバヌネむバヌ」によっお読み取られる「シヌクレット」が保存されおいるデヌタベヌスぞの蚌明曞ファむルたたはパスワヌドが䜜成される可胜性がありたす。 パスワヌド、暩限、アクセス制限の蚭定を忘れないでください。 しかし、誰もがこれを知っおいるので誰もが知っおいるわけではありたせんが、私は長い間広めたせん。



7.別のタむプの脆匱性は、プロトコルを実装するずきにプログラマヌによっお䜜成されたものです。 簡単な䟋を挙げたしょう幞いなこずに、深刻な脆匱性ではありたせん2幎前、OpenIDサヌバヌの5぀の最も人気のある実装の2぀で、開発者はlife_time秒単䜍のキヌの有効期間ずexpires_time秒単䜍のキヌの有効期限の抂念を混同したした1970幎1月1日。 コヌドの特に重芁なセクションをプロゞェクトの他の参加者が芋るこずができるようにするこずが望たしいですOK、これもありふれたものですか-その埌、結論に進みたす。



結論



この蚘事で䌝えたかった䞻なアむデアは、著者が有名䌁業であっおも、特定のプロトコルの開発者に䟝存しないこずです。 自分で考え、自分で決めおください。



実践に぀いお少しだけでなく、蚘事の範囲を超えたものに぀いおも。



More articles:


All Articles