Python Flaskアプリケーションを安全にする方法
Gourav Singh Bais
2024年5月21日
0 分で読めますFlaskは、Python向けの強力で軽量、かつ柔軟なウェブフレームワークです。定型コードを最小限に抑えながら、開発者がウェブアプリケーションをすばやく開発できるよう設計されています。追加のライブラリやツールを必要としない独立したマイクロフレームワークで、データベース抽象化レイヤーもありません。
Flaskにはルーティング、テンプレートのレンダリング、リクエスト処理などの機能があり、シンプルさと柔軟性で知られるWeb Server Gateway Interface(WSGI)標準に準拠しています。
残念ながら、ほかのウェブフレームワークと同様、適切に保護されていないFlaskには脆弱性が生じる可能性があります。Flaskで最も一般的なセキュリティリスクには、クロスサイトスクリプティング(XSS)、クロスサイトリクエストフォージェリ(CSRF)、SQLインジェクションがあります。
Snyk Vulnerability Databaseでは、PythonのFlaskライブラリで見つかった数多くのセキュリティ脆弱性を確認できます。

この記事では、Flaskウェブアプリケーションフレームワークで構築したPythonアプリケーションを安全にするためのベストプラクティスを紹介します。まず、安全でない設定例を確認し、問題を緩和して修正する方法を学びます。
Web Server Gateway Interface(WSGI)標準とは何ですか?
WSGIは、WebサーバーがPythonで記述されたWebアプリケーションと標準化された方法で通信できるようにします。WebサーバーからWebアプリケーションやフレームワークへリクエストを転送し、クライアントにレスポンスを返すための仲介レイヤーです。
WSGIが重要なのはなぜですか?
WSGIが登場する前は、PythonのWebフレームワークとサーバーは特定の組み合わせに依存していることが多く、特定のWebフレームワークは限られたWebサーバーでしか動作しませんでした。WSGIはこの制約を解消し、柔軟性と相互運用性を高めました。
WSGIは、他の言語における類似の概念とどのように異なりますか?
WSGIは、JavaのJava Servlet APIやRubyのRackと目的が似ています。これらの技術はHTTPリクエストとレスポンスの詳細を抽象化し、開発者が基盤となるサーバーとの通信を処理するのではなく、Webアプリケーションのロジックの実装に集中できるようにします。
Python Flaskアプリケーションの安全でない設定
以下は、Python Flaskアプリケーションに影響する一般的な安全でない設定の問題です。開発者は、コードベースで同じ間違いを繰り返さないよう十分に注意する必要があります。
シークレットキーの露出
Flaskのシークレットキー、APIキー、パスワードなどの機密情報をソースコードに含めてしまうのは、よくあるセキュリティ上の不備です。機密情報をソースコードに直接埋め込むと、悪意のある攻撃者がこの脆弱性を悪用して、さまざまなサービスに不正アクセスするおそれがあり、大きなセキュリティリスクとなります。
シークレットキーとAPIキーを誤ってソースコードにハードコードしてしまうと、次のようになります。
ヒント:この機会にIDEにSnyk拡張機能をインストールしてみましょう。エディターに表示されている青い波線のように、シークレットキーの露出を視覚的に確認できます。

この場合、シークレットキーの露出を防ぐには、キーを安全に生成する必要があります。生成方法はいくつかありますが、よく使われる方法の1つはuuidモジュールを使うことです。uuidモジュールは、主にRFC 4122で定義された原則に基づいて、汎用一意識別子(UUID)を生成するために使われます。このモジュールは、シークレットキーとして使用できる32バイトのランダムな16進数文字列を生成します。
安全なキーを生成するには、コードでuuidモジュールをインポートし、uuid4().hex機能を使用します。
ただし、シークレットキーを生成するだけでは不十分です。Flaskアプリで安全に使用する必要もあります。推奨される方法は、シークレットキーをenvironment variableに設定するか、暗号化した設定ファイルに保存することです。シークレットキーをenvironment variableに設定する場合は、次のようになります。
開発者は、認証情報を環境変数に保存して、データ漏えい、不正アクセス、悪用の可能性を防ぐため、12 factor appで推奨されているような設定規約に従う必要があります。
デバッグモードが有効
デバッグモードは通常、開発環境で使用するもので、詳細なエラーメッセージやアプリケーションの状態に関する包括的な情報を提供します。しかし、本番環境でこのモードを有効にすると、機密情報やシステムの内部動作が露出します。
たとえば、このFlaskウェブアプリケーションでは、本番環境でデバッグモードが有効になっています。
ここではデバッグモードがTrueに設定されています。そのため、本番環境でエラーが発生すると、ユーザー名やパスワードなどの機密情報がデバッグコンソールに表示されるおそれがあります。
このような場合、デバッグモードをTrueに設定したことを忘れたまま、本番環境へのデプロイ前に変更し忘れてしまうのは簡単です。そのため、コードやアプリケーションの脆弱性を発見し、修正するのに役立つSnykのようなプラットフォームを利用するのがおすすめです。SnykはPython、Go、PHP、JavaScriptなど、幅広いプログラミング言語に対応しています。
さらに、SnykはVisual Studio CodeやPyCharmなどの各種IDEのほか、Jenkins、CircleCI、MavenなどのCIパイプラインやワークフローにも簡単に統合できます。
たとえば、このデバッグのシナリオでSnykを使うには、Visual Studio Codeで「Snyk」を検索してインストールするだけです。

インストールすると、Snykが左側のパネルに表示されます。まだSnykアカウントをお持ちでない場合は、Connectボタンをクリックしてログインするか、アカウントを作成してください。すると、次のようなブラウザーウィンドウが表示されます。

接続したらVisual Studio Codeに戻り、Flaskスクリプトを保存しているフォルダーを開きます。コード内の脆弱性が表示されます。

ご覧のとおり、Snykはデバッグモードがまだ有効であることを検出しました。この問題を解決するには、デバッグモードをFalseに設定してFlaskアプリケーションを安全にします。
本番環境でデバッグモードを無効にするだけでなく、ロギング機能を使ってアプリケーションのログを収集し、コードに問題がないか確認する必要もあります。
設定ファイル内の機密データが保護されていない
Flaskアプリケーションでは、データベースの認証情報、APIキー、暗号化キーなどの重要な情報を設定ファイルに保存するのが一般的です。しかし、ファイルを保護せずに置いておくと、データが漏えいするおそれがあります。
設定ファイル(通常はconfig.ini)にデータベース接続用の認証情報が保存されている、次の例を見てみましょう。
ここではユーザー名とパスワードが平文で記載されています。攻撃者がこのファイルにアクセスすると、認証情報を使って機密情報にアクセスできてしまいます。
この問題を解決する最善の方法は、設定ファイルを使わず、環境変数に認証情報を保存することです。必要な情報を.bash_profileなどの隠しファイルにまとめて保存する環境変数を使えば、このファイルをgitignoreに追加して、攻撃者が容易にアクセスできるGitやBitbucketなどのバージョン管理プラットフォームに誤ってプッシュされないようにできます。
Flaskアプリで設定ファイルを使う必要がある場合は、機密データが暗号化されていることを確認してください。
ここでは、パスワードを表すためにプレースホルダーまたは暗号化された値を使用しています。この場合、外部の安全な鍵管理システムや安全な復号手法を使って、実行時に機密データにアクセスできます。
Flaskアプリケーションの脆弱性
Python Flaskアプリケーションで安全でない設定がどのようなものかを理解したところで、Flaskアプリケーションにも影響する一般的なウェブセキュリティの脆弱性を見ていきましょう。
クロスサイトスクリプティング(XSS)
XSSは、攻撃者が任意のJavaScriptまたはHTMLコードをウェブページに挿入しようとするウェブセキュリティ上の脆弱性です。これにより、攻撃者はユーザーのブラウザーで悪意のあるスクリプトを実行できます。
Flaskで使われるテンプレートエンジンのJinja2には、XSSの脆弱性に対処するための自動エスケープ機能があります。デフォルトではすべての変数が自動的にエスケープされます(つまり、明示的に指定しない限りHTML要素は含まれません)。そのため、HTMLやJavaScriptコードを含むユーザー入力はJinja2によって安全にエスケープされ、悪意のあるスクリプトの実行を防ぎます。
自動エスケープがFalseに設定されている場合、FlaskアプリケーションはXSSの脆弱性にさらされます。たとえば、ページの表示にユーザー入力が必要なウェブアプリケーションを考えてみましょう。
自動エスケープがfalseに設定された対応するindex.htmlページは、次のようになります。
攻撃者がinputパラメーターを通じて悪意のあるスクリプトを挿入すると、ページの表示時に実行され、データ窃取、アカウント乗っ取り、フィッシング攻撃などのセキュリティリスクにつながるおそれがあります。
XSSを防ぐには、テキストを適切にエスケープし、HTML要素が含まれないようにウェブサイトを設定する必要があります。自動エスケープをtrueに設定するだけで、FlaskアプリケーションへのXSS攻撃を防げます。
XSSを防ぐもう1つの方法は、明示的なマークアップのエスケープです。これを実装するには、ウェブページで|safeフィルターを次のように使用します。
ただし、|safeを使う際は十分な注意が必要です。安全と指定したコンテンツに悪意のあるスクリプトが含まれていないことが前提となるためです。
Pythonのクロスサイトスクリプティングの脆弱性について詳しく知りたい方は、Snyk Learnの短時間で学べるセキュリティレッスンをご覧ください。
クロスサイトリクエストフォージェリ(CSRF)
CSRFは、被害者をだまして悪意のあるリクエストを送信させる攻撃です。ウェブアプリケーションにおけるCSRFでは、攻撃者が正規ユーザーになりすまして、ウェブページに不正なリクエストを送信します。たとえばFacebookのようなプラットフォームでは、グループに画像を送信し、グループのユーザーがその画像をクリックするとアカウントが削除される、といった攻撃が見られます。
CSRFをよりよく理解するために、次のようなCSRF保護のない、状態を変更するシンプルなアプリケーションを考えてみましょう。
このコードは、POSTリクエストでフォームを送信してパスワードを変更します。CSRF対策がないため、攻撃者は細工したHTMLやスクリプトを含む別のウェブサイトにユーザーを誘導し、パスワードを変更させることができます。CSRF保護のないフォームは次のようになります。
CSRFの脆弱性を防ぐには、Flask-WTF拡張機能とCSRFProtectミドルウェアを使用します。Flask-WTFはWTFormsライブラリを組み込んだFlaskプラグインです。Flaskウェブアプリケーションのフォームを簡単に生成、管理するための便利な機能を提供します。
次のようにpipを使ってインストールできます。
インストールしたら、CSRF保護のためにFlask-WTFを使ってFlaskアプリケーションを更新できます。
ここでは、CSRFProtectをFlaskアプリで初期化し、SECRET_KEYを設定しています。このキーはCSRFトークンの作成と検証に使用されます。
テンプレート(index.html)も忘れずに更新し、次のようにCSRFトークンを含めてください。
このcsrf_token()関数は、CSRFトークンを含む非表示の入力フィールドを生成します。フォームの送信時にFlask-WTFがトークンを検証し、リクエストがCSRF攻撃でないことを確認します。
FSQLインジェクションとデータベースのセキュリティ
次に、データベースのセキュリティに関連するFlaskの問題をいくつか見てみましょう。
SQLインジェクション
SQLインジェクションは、SQLクエリで使用されるパラメーターを操作し、攻撃者がデータベース上で任意のSQLコードを実行する深刻な問題です。不正アクセス、データの改ざん、機密情報の漏えいにつながるおそれがあります。
Flaskアプリケーションでは、SQLクエリに使用する前に入力が適切にサニタイズされていないと、SQLインジェクション攻撃が発生する可能性があります。
この攻撃をよりよく理解するために、データベースからデータを取得するFlaskコードの例を見てみましょう。
このクエリは、クエリ文字列からユーザー名とパスワードを取得します。攻撃者が' OR '1'='1'; -- のような入力を挿入すると、クエリは次のようになります。
このクエリは常にTrueとなるため、攻撃者はログインしてデータに不正アクセスできてしまいます。
SQLインジェクションの影響を受けやすいコードを特定するのは困難ですが、Snykなら対応できます。Visual Studio CodeでSnykをすでに設定しているのであれば、スクリプトを開くだけで、SnykがSQLインジェクションの問題を自動検出します。

このSQLインジェクション攻撃を軽減する簡単な方法は、パラメーター化クエリまたはステートメントを使用することです。
Flaskでは、カーソルオブジェクトのexecuteメソッドを使ってパラメーターを安全にバインドすることもできます。パラメーター化クエリは次のようになります。
このコードでは?プレースホルダーを使用し、実際の値をexecuteメソッドにタプルとして渡します。これにより、ユーザー入力は実行可能なSQLコードではなくデータとして扱われます。
この種の攻撃を避けるため、ユーザー入力は必ず検証・サニタイズしてください。エスケープ文字、サードパーティ製ライブラリ、正規表現などの手法を使って入力をサニタイズできます。
SQLインジェクションについて詳しく解説した記事として、SQLインジェクション対策チートシート:攻撃を防ぐ8つのベストプラクティスをおすすめします。
認証と認可
認証と認可は、Webセキュリティの重要な要素です。認証や認可が侵害されると、さまざまなセキュリティ問題につながる可能性があります。次に、その具体例を見ていきましょう。
認証に関するセキュリティ問題
よくある認証関連のセキュリティ問題の一つがブルートフォース攻撃です。攻撃者がユーザー名とパスワードを何度も推測し、Webサイトやサービスへのアクセスを試みます。また、セッション固定攻撃もよくある問題です。これは、フィッシング攻撃などを通じて、攻撃者がセッションIDを既知の値に設定するものです。
ブルートフォース攻撃を軽減するには、セッションロックアウトの仕組みを実装する必要があります。この方法では、ログインに一定回数失敗すると、ユーザーをロックアウトします。
このコードではMAX_LOGIN_ATTEMPTSを3に設定しています。つまり、認証情報を3回より多く間違えると、ユーザーはロックアウトされます。
login()メソッドではusernameとpasswordを取得し、ユーザーがロックアウトされているか確認します。ロックアウトされていなければ、ログイン試行を確認します。認証情報が正しければログインできます。間違っている場合はログイン試行回数を1増やし、ログインに成功するかロックアウトされるまで、この処理を繰り返します。
セッションロックアウトの仕組みに加えて、強力なパスワードポリシーを適用し、多要素認証(MFA)の導入も検討しましょう。
セッション固定の問題を軽減するには、ユーザーのログイン後、または一定時間が経過した後(自動失効)に、ユーザーがログインを継続していてもセッションIDを再生成します。
このコードでは、ユーザーのログイン成功後にlogin()メソッドがregenerate() メソッドを使ってセッションIDを再生成します。
認可に関するセキュリティ問題
Webアプリのすべての機能が、すべてのユーザーを対象としているわけではありません(つまり、特定のユーザーが利用できる機能は限定されるべきです)。ユーザーに適切なロールが割り当てられていないと、不正アクセスが発生する可能性があります。そのため、ロールベースのアクセス制御(RBAC)が必要です。
認証済みユーザーがパラメーターやURLを操作して、許可されていないリソースにアクセスすることもあります。これは、しばしば安全でない直接オブジェクト参照(IDOR)と呼ばれます。詳しくは、Pythonで安全でない直接オブジェクト参照を見つけて修正する方法の記事をぜひご覧ください。
RBACやIDORの問題を解決するには、ユーザーに特定のロールを割り当て、そのロールに基づいてアクセス制御を適用する必要があります。例を見てみましょう。
このコードでは、admin_dashboard()メソッドが、アクセスロールがadminの場合に利用できる機能を実装しています。それ以外の場合はUnauthorized accessという警告を返します。
また、ユーザーが許可されたリソースだけにアクセスできるよう、アクセス制御を管理する必要があります。
認証情報を平文で保存してはいけません。攻撃者に簡単に取得され、悪用されるおそれがあります。これを防ぐには、ハッシュ化とソルトを使ってユーザーの認証情報を保存します。
ハッシュ化では、パスワードを固定長の文字列に変換します。この処理を逆にたどって元のパスワードを得ることは、計算上ほぼ不可能です。ソルトとは、ハッシュ化の前に各パスワードへ追加する一意のランダムな値です。レインボーテーブル攻撃などの防止に役立ちます。
古いライブラリとセキュリティ更新
古いFlaskライブラリを使っていると、攻撃者に悪用される脆弱性が含まれている可能性があります。ライブラリでは、脆弱性に対処するためのセキュリティ更新やパッチが公開されることがよくあります。常に最新のパッケージを使うようにしてください。
最新のセキュリティパッチを適用するには、pipやcondaなどのツールを利用できます。さらに、Snykなどのツールでコード全体の依存関係とInfrastructure as Code(IaC)構成をスキャンできます。
もう一つのベストプラクティスは、requirements.txtファイルで依存関係のバージョンを固定することです。これにより、プロジェクトで使用するバージョンが明確になり、開発者は更新を管理し、互換性をテストできます。
ファイルアップロードの保護
FlaskのWebサイトで、誰でもあらゆる種類のファイルをアップロードできるようにすると、さまざまな問題が発生するおそれがあります。たとえば、攻撃者が悪意のあるファイルをサーバーにアップロードすると、既存ファイルを上書きされる可能性があるほか、サービス拒否(DoS)攻撃につながることがあります。また、実行可能ファイルによって、さまざまな種類のコンピューターウイルスが実行される可能性もあります。
以下は、あらゆるユーザーが任意のファイルをアップロードできるコードの例です。
このコードでは、upload_file()メソッドがユーザーから提供されたファイルを読み込み、uploadsフォルダーに保存します。
安全でないファイルを防ぐための最初の対策は、許可するファイル拡張子を定義することです。Flaskアプリでは、実行可能ファイルやスクリプトファイルを決して許可しないでください。
また、不正アクセスを防ぐため、ファイルは安全な場所に保存してください。
ここでは、複数の条件を適用してファイル形式が正しいかどうか確認しています。
上書きを防ぎ、予測可能な命名規則によるリスクを抑えるために、ファイル名をランダム化することも有効なベストプラクティスです。
エラー処理と情報漏えい
どのようなアプリケーションでも、エラー処理は重要です。本番環境でprint文を使ったり、デバッグモードを有効にしたりするのは避けましょう。不適切なログの仕組みを使うと、アプリケーションに関する重要な情報が漏れる可能性があります。
たとえば、本番環境で詳細なエラーメッセージを表示すると、アプリケーションの内部情報が漏れ、攻撃者が潜在的な脆弱性を特定しやすくなります。
この例では、Flaskアプリに関連付けられたデータベースの重要な情報が漏れています。
また、エラーレスポンスにトレースバック全体を表示すると、アプリケーションのコード構造が明らかになり、次の例のように脆弱性が露呈する可能性があります。
エラー処理による情報漏えいを軽減するには、機密情報を公開せずに、一般的なエラーコード(例:404 Not Found、500 Internal Server Error)に対するカスタムエラーページを作成できます。そのためには、errorhandlerデコレーターを使ってカスタムエラーハンドラーを定義します。
さらに、例外やエラーを適切にログに記録しましょう。ログメッセージはデバッグに十分な詳細を含めつつ、機密情報を漏らさないようにする必要があります。
これらのベストプラクティスに従えば、堅牢で安全なFlaskアプリケーションを実現できます。
まとめ
Flaskは、小規模から中規模のWebアプリケーションで広く使われているWebフレームワークです。しかし、他のWeb開発ツールやフレームワークと同様、適切に扱わなければ問題が発生することがあります。こうした問題を理解するだけでなく、悪意ある攻撃者に悪用されないよう、対策を講じることが重要です。
この記事で取り上げたFlaskアプリケーションのセキュリティに関するトピックの実用例については、GitHubのこちらのコードリポジトリをご覧ください。
Snykを使えば、コードの脆弱性を簡単に見つけて軽減できます。Snykはさまざまなプログラミング言語に対応し、ツール、パイプライン、ワークフローにシームレスに統合できます。今すぐSnykを無料で始めましょう。
最後に、SnykのPythonセキュリティのベストプラクティス・チートシートをぜひご活用ください。また、無料のSnyk Learnサイトで、Pythonのアプリケーションセキュリティスキルを身につけましょう。



