Twitterで開発をする際には、スパムを拡散させ、マルウェアをインストールし、ウェブを混乱に陥れることを目的としたハッカーの危険性を認識しておいてください。 そのために、このページでは実在する多くの脅威と、可能な限りアプリケーションの安全を保つために使えるベストプラクティスを説明します。
このページに追加すべき情報があると思うのであれば、我々に教えてください。 Twitterに直接影響するセキュリティの問題を見つけた場合は、Twitter のセキュリティ担当に連絡してください。 If your security issue is legitimate, we can give you attribution for the discovery on our Security Contributors page upon request.
以降で説明する脅威は、あなたが使用しているプラットフォームに関係なく影響を受けるものです。 Twitterのプラットフォームやその他インタネット上の場所でサービスを構築する際には、こうした脅威を念頭に置いてください。
要するに、アプリケーション内でユーザーのパスワードを保持してはいけません。その代わりに可能な限り OAuth トークンを使ってください。 その他機密情報は必要に応じて暗号化してください
ユーザーが有効で信頼できるデータを送信するとは思わないでください。 文字列の長さは正しいか、有効なファイル形式化などを確認し、データをサニタイズ(無害化)してください。 Twitter ではAPIに送信されたデータをサニタイズしていますが、クライアント側で少し考慮してくれるだけで大きな助けになります。 あなたのアプリケーションで使用できる入力形式をホワイトリストに登録し、ホワイトリストにないものは全て破棄してください。
Twitterでは全てのREST API メソッドを SSL上で提供しています。 あなたのコードが信頼できないネットワーク上で動作する可能性がある場合は(クライアントアプリケーションを開発している場合)、認証済みリクエストや機密性の高いリクエストは全て、常にSSL を使用してください。 例えば、ツイートを投稿したり、最新のダイレクトメッセージをリクエストしたり、プロフィール属性を更新するといった操作をTwitter クライアントで行う場合は、SSL 上で処理を実行してください。SSL と合わせてOAuthを使用すると安全なので、そちらを推奨します あなたが使用しているホスティングプロバイダーが信頼できるのでれば(もしくは自分のサーバ上でホスティングしているのであれば)、サービス間連携でSSLを使うメリットはないかもしれません。
Twitter APIでは各呼び出しを認証するのに OAuth を使用しています。トークンとトークン秘密情報を扱う場合は、それら(とその他機密情報)を可能な限り安全な方法で暗号化してください。Twitterでは、必要に応じて bcrypt-ruby を使用しています。
デバッグ画面やデバッグログで、機密情報を表示しないようにしてください。あなたのアプリケーションが適切に設定されていない場合、ウェブフレームワークによっては簡単にデバッグ情報にアクセスできるものがあります。デスクトップアプリやモバイルアプリを開発する場合、うっかりデバッグフラグやデバッグシンボルを有効にしたままアプリを公開してしまうことも有り得ます。 Build checks for these configurations into your deployment/build process.
テストを行う場合は(ちゃんとテストしていますよね？)、動作すべき機能が適切に動作するかだけでなく、動作すべきでない機能が適切に動作しないかについてもテストしてください。自分を攻撃者の立場に置き換えて、悪意のあるテストを実施してください。
security@yourapplication.comは設定していますか? Do those emails go right to your phone? Make it easy for people to contact you about potential security issues with your application. If someone does report a security flaw to you, be nice to them; they’ve just done you a huge favor. Thank them for their time and fix the issue promptly. It’s fairly common for security researchers to write about vulnerabilities they’ve discovered once the hole has been closed, so don’t be upset if your application ends up in a blog post or research paper. Security is hard, and nobody is perfect. As long as you’re fixing the issues that are reported to you, you’re doing right.
Consider hiring security professionals to do an audit and/or penetration test. You can’t depend solely on the kindness of strangers; for every vulnerability that someone was nice enough to report to you, there’s ten more that malicious hackers have found. A good security firm will dig deep to uncover issues. Look for firms and individual consultants that do more than run a few automated tools.
あなたのアプリケーションがお金を扱っている場合(もしくはこれから扱う予定の場合)、法律により特定のセキュリティ対策や規制を求められる場合があります。 あなたのアプリケーションにあった対応を探し、コードを修正するようにしてください。
入力内容の有効性を確認するための簡単な手法の一つが FIEO です: 入力をフィルタ、出力をエスケープ(Filter Input, Escape Output)。 Twitter APIデータ、クッキーデータ、ユーザーの入力内容、URLパラメータ、データベースのデータなどを含む、あなたのアプリケーション外から来る全てをフィルタしてください。 あなたのデータベースサーバへ送られるSQL、ユーザーのブラウザへ送られるHTM、ほかのシステムへ送られるJSON/XML出力、シェルプログラムへ送られるコマンドを含む、あなたのアプリケーションから送信される全ての出力をエスケープしてください。
XSS attacks are, by most measures, the most common form of security problem on the web. In short, if an attacker can get their own JavaScript code into your application, they can do bad stuff. Anywhere you store and display untrusted, user-supplied data needs to be checked, sanitized, and HTML escaped. Getting this right is hard, because hackers have many different ways to land XSS attacks. Your language or web development framework probably has a popular, well-tested mechanism for defending against cross-site scripting; please make use of it.
Generally: if HTML isn’t needed from some user-facing form, filter it out; for example, there’s no reason to allow anything other than integers when storing a phone number. If HTML is needed, use a known-good whitelist filter. HTMLPurifier for PHP is one such solution. Different contexts may require different filtering approaches. See the OWASP XSS Prevention Cheat Sheet for more on filtering.
あなたのアプリケーションがデータベースを使用している場合、SQL インジェクションに注意する必要があります。 また、入力を受け付ける場所は、攻撃者の標的となって入力フィールドを突破され、データベースに侵入される可能性があります。 SQL インジェクションを防ぐロジックが組み込まれたデータベースライブラリを使用してください。 ライブラリを使用せずにカスタムSQL文を記述する場合は、攻撃性の高いテストを実施してSQLインジェクションの危険性がないことを確認するようにしてください。
SQLインジェクションを防ぐためのメインとなる二つの方法は、SQL文を作成する前にエスケープする方法と、パラメータ化された入力を使ってSQL文を作成する方法です。 プログラマーが間違えにくいので、後者の方法を推奨します。
Are you sure that requests to your application are coming from your application? CSRF attacks exploit this lack of knowledge by forcing logged-in users of your site to silently open URLs that perform actions. In the case of a Twitter app, this could mean that attackers are using your app to force users to post unwanted tweets or follow spam accounts. You can learn more about this sort of attack on PHP security expert Chris Shiflett’s blog.
The most thorough way to deal with CSRF is to include a random token in every form that’s stored someplace trusted; if a form doesn’t have the right token, throw an error. Modern web frameworks have systematic ways of handling this, and might even be doing it by default if you’re lucky. A simple preventative step (but by no means the only step you should take) is to make any actions that create, modify, or destroy data require a POST request.
CAPTCHAを使用すれば、スパマーや攻撃者の動作を遅らせることができます。
あなたのれ部アプリケーションで問題が発生したと考えた時、どうやってそれを見つけますか? 致命的な例外やエラーが発した場合はあなたにメールを送信し、詳細なログを保持するようにしてください。 You may want to put together a dashboard of critical statistics so that you can see at a glance if something is going wrong (or staying right).
We could use suggestions from desktop developers about the security issues they’ve run into. Developers working in sufficiently high-level languages shouldn’t be dealing with buffer overflows and the usual security issues. What have you defended against?
前述したように、最適なセキュリティのためには OAuthを使用する必要があります。 しかし、ユーザーの代わりにリクエストを作成するためのトークンを取得した後に、それをどこに保管すればいいのでしょうか? 理想的なのは、あなたのオペレーションシステムで管理されている暗号化された領域がいいでしょう Mac OS Xの場合、キーチェインがこれに該当します。 GNOME デスクトップ環境の場合、キーリングがあります。 KDE デスクトップ環境の場合、Kウォレットがあります。
以下のリンクを読めば、セキュリティに関する詳細が学べます。 Security is a deep topic, but don’t feel like you have to learn everything about it before taking proactive steps to lock down your application. A little security-mindedness goes a long way.