クライアントサーバーAPIセキュリティテスト

2年前、私はCodeFestカンファレンスで「Pentest on steroids。 プロセスを自動化します」と、プレゼンテーションを記事として書き直しました。 今年、私は非常に喜んで会議に参加し、「BlackBoxクライアント/サーバーAPIセキュリティテスト」というトピックで講演しました。明らかに伝統として、スピーチも語っています。

APIの脆弱性が見つかりました。 真実は。

何言ってるの？

APIについて話しますが、APIは異なる場合があります-オペレーティングシステム、サイト、デスクトッププログラムのAPIですが、少なくとも何かです。 つまり、APIは特定のメソッドを介して何かのメソッド（たとえば、OSの場合、ファイルに書き込む）にアピールします。 そして、含むファイルの起動。 コマンドの結果は完全に異なりますが、開発の観点も同様の方法で（OS APIメソッドを介して）発生します。 Webテクノロジーでは、多くの人がプロジェクト用のAPIも実装しています。指で操作する場合は、ソーシャルにメッセージを送信できます。 サイトにアクセスしてネットワークを構築するか、特別なHTTPリクエストを作成してネットワークを構築できます。 また、このような機能の代替使用を実装すると、セキュリティエラーが発生します（他の場所と同様）。 この記事では、Webプロジェクトに同様の機能を実装する際の特定のエラーについてのみ説明しています。

インターフェイスからAPIメソッドへ

YouTubeでは、広く知られていませんが、APIの脆弱性を分析します。 YouTubeでは、インターフェースからのスペシャルの使用を禁止しています。 クリップのタイトルにある<and>（htmlタグやXSS攻撃に必要）などの文字。 しかし！ APIを見つけて、同じビデオの名前を変更しようとすると、すべてが成功します。 その結果、いいえ、xssはyoutubeページで実行されませんでした。 しかし、それはGmailへの手紙で実行されました（ビデオ付きの手紙が到着したとき）。これはさらに重要です。



結論は？ 論理的に-問題はさまざまな方法にあります。 しかし、なぜそれが起こったのかはもっと興味深い質問です。 ここでは、以下を強調します。

• ほとんどすべての大規模なプロジェクトはOOPとMVCのようなパターンを使用します。 また、APIの実装は、インターフェイスのメソッドから単純に継承し、その制限をすべて取り除く必要があります。 類似または類似のテンプレートであり、メソッドがゼロから作成された（ナンセンス？誰が知っている）か、インターフェースのカスタム「ハック」であることを意味します。
• カスタムハック？ もちろん、開発者の問題。 しかし、チームリーダーでもあるため、どこで何を実装する必要があるかを開発者に常に通知する必要があります。 つまり すべての永遠のスレッドを明確に理解する：開発プロセスのどこでデータを検証するか（モデル、サービス、コントローラー、その他）。 これらは開発で複雑なパターンを使用する問題の結果であり、timlidは通常理解しています。開発者はプロジェクトの検証の一部にも別の場所にも到達しません。 APIは正しく継承されていますが、脆弱性があります。

テスターに​​とってはどうですか？

1. インターフェイス（その制限）について知っていたすべてを完全に忘れて、プロジェクトを最初からテストする必要があります。
2. パラメーターの変更を確認します。これは、FaceBookに関する画面を使用した鮮明な例です。インターフェイスからは送信者IDを置き換えることはできませんでしたが、APIからはできました。
3. sqli / xssなどの「標準」攻撃を確認してください。
4. 自動テストがある場合、これはクールです。 testValue1などの標準ペイロードを '、 "、>、<などのさまざまな特殊文字に置き換えて、それらを一致させることができます（XSSを探します）。

圧縮

多くの場合、モバイルデバイスで使用するAPIの開発が開始されます。 また、実装する場合は、送信する前にさまざまな圧縮を追加し、受け入れた後に解凍します。 また、ZIP爆弾のような古いひげを生やした攻撃（さまざまなファイルホスティングサービスが彼女に付け加えました）があります。 問題は、開梱時に42 kbのアーカイブに到達できるサイズはどれくらいですか？ 4.5ペタバイト 。 こちらとこちらからダウンロードしてください 。 一番下の行は単純です-ゼロで満たされたファイルが作成され、圧縮されます。 したがって、圧縮、またはむしろ解凍は危険なことです、注意してください。

イービル・ジェイソン

APIはエンドユーザーだけでなく、プロジェクト内でデータを送信するために提供されることもあります。 これは多くの場合、異なるドメインを持つ大規模なサイトで見られます。 そしてどういうわけか、クライアント側でドメイン間でやり取りする必要があり、ここでJSONPが助けになります。 これは、ドメイン1に必要なJSONがあり、コールバックになります。 ドメイン1にアクセスすると、ユーザーはCookieを送信します。ユーザーが承認されているかどうかを確認し、必要なデータを提供できます。 2番目のドメインでは、同様のJSが挿入されます

<script type="application/javascript" src="http://server1.example.com/api/getUserInfo?jsonp=parseResponse"> </script>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

parseResponse関数が既に定義されています。 しかし、肝心なのは、攻撃者がこのスクリプトを自分のドメインに貼り付けて、コールバックを判断し、意味のあるデータがある場合は、それを何らかの方法で使用できることです。 このような脆弱性の優れた使用例は、記事「Fighting Anonymity」に示されています。

暗号化

APIについて話すと、彼らはすぐにリクエストに署名します。 APIへのアクセスは多くの場合、さまざまなユーザーに発行されるため、ユーザーの識別スキームが必要です。 そして、ほとんどの場合、彼らは次のスキームを使用します。それぞれに独自のAPIキーが与えられ、開発者はこのキーを使用してリクエストに署名します。



sign = sha*(... + DATA + ...)







データ-省略記号APIキーの代わりに送信するデータ。

そして問題は、キーをどこに置くか、左か右かです。 右側のみ （同様の非常に一般的なスキームを使用してリクエストに署名することについて話している）。 なんで？ 回線延長に攻撃があります。 よく見てみましょう。

データがA = 1＆B = 2＆C = 3であり、署名が07ce36c769ae130708258fb5dfa3d37ca5a67514であり、署名が間違ったスキームsign = sha1（KEY + DATA）にあるとします。

そして今、状況：誰かがクライアントからサーバーへのリクエストを1つだけ傍受し、リクエスト内のデータを変更したいのですが、新しい署名が必要であり、署名のキーは送信されません（論理的です）。 彼は何を知っていますか？ 元のデータとその署名。 要するに、行の拡張を作成して（データを追加する）、先頭のNバイトを知らなくても新しい署名（ハッシュ）を作成する技術的な可能性があります。 実際には、先頭がハッシュされたときにNバイトのインデントが設定された新しいデータは、 A = 1＆B = 2＆C = 3 \ x80 \ x00 \ x00 ... \ x02＆C = 4のようになります。 どこで

• A = 1＆B = 2＆C = 3-初期データ
• \ x80 \ x00 \ x00 ... \ x02-特別。 ハッシュ時のインデント（署名のキー）のバイト
• ＆c = 4-新しいデータ

同じパラメーター（PHPなど）を送信する場合、2番目のパラメーターが使用されます。 あなたが攻撃するために必要なものだけ。 最初から影響を与えることはできません



Evilが勝ちました：署名する鍵を知らなくても、リクエストに署名し、パラメータを変更できます。 そして、API VKとMail.RUを操作するためのドキュメントからの抜粋です。

  Vkontakte：sig = md5（name1 = value1name2 = value2api_secret） 
 Mail.RU sig = md5（uid + params + private_key） 

ご覧のとおり、キーは右側にあります。



1件のリクエストの盗難について言及しました。 実際には、これは思ったより少し簡単です（ストーリー＃1、 記事 ）

安全でないXML

誰もが、目立たないデータ型であるXMLに遭遇したと思います。

 <recipe name="" preptime="5" cooktime="180"> <title> </title> <composition> <ingredient amount="3" unit=""></ingredient> </composition> ... </recipe>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、XMLのエンティティに遭遇した人は少ない



DTDの例：

 <!ENTITY writer "Donald Duck."> <!ENTITY copyright "Copyright W3Schools.">
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

XMLの例：

 <author>&writer;©right;</author>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、何かを定義してから再利用できます。 上記の例は単なる文字列です。

外部のXMLエンティティに出くわした人はさらに少なくなりました...

 <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <foo>&xxe;</foo>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

外部の何か、ローカルファイル、http経由の外部ファイルなどがエンティティとして機能します。 つまり これは標準です。 最初は、良い目的で考えられていました。たとえば、XMLをクライアントに渡し、現在の時間を別のサーバー（HTTP経由でアクセス可能な別のxmlファイル）から取得する必要があります。



長い議論がなければ、この脆弱性は明らかです。 さまざまなラッパーの使用-ファイル：///、http：//攻撃者はシステム、ネットワークなどに関する情報を受け取ることができます。 これにより、コマンドのリモート実行が行われる場合があります。たとえば、PHPにはexpect：//ラッパーがあり、最初にOSでコマンドを実行し、その結果を返します。 そのため、デフォルトでは、すべての標準XMLパーサーがこの攻撃の影響を受けます。 その方法の1つは、外部エンティティのサポートを無効にすることです。 その後、攻撃者はXML爆弾を使用できます。

 <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、サーバーを「置く」。 一番下の行は、エンティティをエンティティに常に転送することです。

これはサーバーだけでなくクライアントの問題にもなり得ることを覚えておく価値があります（たとえば、クライアントを欺くソフトウェアがXMLを解析するなど）。

この脆弱性を使用した最も顕著な例は、2013年11月に発生したFaceBookハックであり 、OSからのコマンドの実行につながる可能性があります。



要約すると：

• まず、インターフェイスのすべての「興味深い」制限をテストします。
• 圧縮に対処する;
• JSコールバックをよく見ます。
• 暗号化。 これは、回線拡張に対する攻撃だけでなく、弱い（たとえば、短い）キー、または何らかの形で予測可能なものでもあります。
• また、モバイルアプリケーションAPIに単純に接続されたデータを見つけることもできます。 ところで、彼らはサービスhttp://hackapp.comを介して見つけることができます。
• XML-XXE
• それ以外。

プレゼンテーション：





デモビデオのsha paddingとXXE：





upd 25/04/0214：レポートの記録