PicolispにおけるWebアプリケーションプログラミングHTMLフォームの作成,パート2

最後のポストでは、グローバル変数を使用してHTMLフォームを作成する方法を示し、なぜこのアプローチにいくつかの制限があるかを説明しました.今日はセッションを使用したより柔軟なアプローチを示し、セキュリティ上の意味についても議論します.

何がセッションですか?
最後の例、「ファーストネーム、ラストネーム」フォームシートをもう一度考えましょう.明らかに、その使用法は非常に限られています:例えば、ユーザーがフォームシートを提出する状況の下で、または、どんな状況でも、それは常に同じ結果を与えます.これは、HTMLプロトコルがステートレスであるためです.新しいクライアントが同じクライアントから来た場合、サーバーは「覚えていません」.
しかし、ほとんどのアプリケーションはそれより複雑な処理を必要とします.たとえば、あなたは、そのユーザーからの以前の情報に応じて画面に表示されているものを適応したいかもしれません.言い換えれば、クライアントとWebサーバとの会話を管理する方法が必要です.
HTTPセッションを使用してこの問題を解決できます.

セッションの初期化
恒久的なセッションを確立するためにはapp 起動時の関数-例えば、HTML関数を呼び出す前に.

(app)
(html 0 "Simple Session *Css NIL
    ...

私たちが再び窓を開くならば、それは変わらないようです.しかし、送信を押すと、URLが直接送信後に変更されます visit here to see the hosted version on picolisp.com ):

Here 例のコードを見つけることができます.
ポートは8080から44573に変わりました、そして、ファイル名は後に続く長い数によって前置されます~ . 何が起こったのですか.
サーバーの子プロセスは、現在、新しい、無料のポートを聞いて開始されています.長い番号(例:64805618275437997)は、サーバーに向かってクライアントを識別するために使用されるセッションキーです.
また、コマンドラインツールを使用して新しいサーバープロセスを識別できますps Linuxで

$ ps ax | grep picolisp
  14151 pts/2    S+     0:00 /usr/bin/picolisp /usr/lib/picolisp/lib.l /usr/bin/pil @lib/http.l @lib/xhtml.l @lib/form.l --server 8080 +
  14172 pts/2    S+     0:00 /usr/bin/picolisp /usr/lib/picolisp/lib.l /usr/bin/pil @lib/http.l @lib/xhtml.l @lib/form.l --server 8080 +

または、あなたが本当に好奇心旺盛であるならば、あなたはPicolispが聞いているポートをチェックしようとすることもできますnetstat :

$ netstat -ltup | grep picolisp
tcp6       0      0 [::]:http-alt           [::]:*                  LISTEN      14151/picolisp      
tcp6       0      0 [::]:47249              [::]:*                  LISTEN      14172/picolisp 

ご覧のように、Picolispはポートhttp "Alt "( 8080 )とポート47249で聞いています.

デバッガを使う
新しく確立されたクライアントサーバー接続の別の効果は、ステータスをチェックするためにデバッガを使用することができます: アプリケーションサーバーの「ターミナル」ウィンドウに表示されます.

$ pil @lib/http.l @lib/xhtml.l @lib/form.l  --server 8080 +
:

我々の価値をチェックしましょう*FirstName 変数

: *FirstName
-> "Mia"

アプリケーション対生産環境
セッションは一般的に“本物の”アプリケーション、すなわち生産環境で必要とされている-私たちは私たちのすべての自分のローカルコンピュータ上で自分のコードを忠実にする限り、我々はそれを必要としません.
このトピックは確かに自分のポストの価値があり、このチュートリアルの最後により詳細に議論します.それにもかかわらず、我々は現在いくつかの点を議論しなければなりません.
ユーザーはポートの変更を見ることができるでしょうか?
以前に見たように、セッションはポート8080からポート44573へのURLのジャンプを引き起こしました.現実世界のアプリケーションでは、これは問題を引き起こします:例えば、これらのポートはファイアウォールで開いていなければなりません、そして、「同じ起源方針」に従い状況は動きません.
したがって、私たちは呼ばれるユーティリティを使用する必要がありますhttpGate 次の作業を行う.

単一のアプリケーション・エントリ・ポート(例えば80または443)を提供する.

PicoliSPアプリケーションをroot権限で実行できます.

オンデマンドのアプリケーションサーバーを起動します.

HTTPS/SSL通信を扱います.

これは、すべてのクライアントがエントリーポート上のサーバーとの接続を構築することを意味し、それはポート12345などの専用のリスニングポートにサーバー側で転送されます.このリスニングポートはURLで表示されます.

http[s]://server.org/12345/path/file

リスニングポートは7分後に自動的に閉じられます.
既に述べたように、私たちは後のポストで生産環境に戻るでしょうhere .
セッションキーを保存するためにクッキーを使うのはなぜですか.
多くのWebフレームワークは、セッションキーを格納するためにクッキーを使用します.URLにキーを保存するのは、より安全ですか?いいえ、それは本質的により危険ではありませんが、それぞれの概念の長所と短所があります.(もちろん、両方を実装することもできます).

長所:1つは、クッキーが必要ないことはいいことだ.これは、JavaScriptとCookieの両方が無効になっている環境でもアプリケーションが動作することを意味します.また、クッキーとは異なり、セッションIDはcross-site scripting attacks .

また、クッキーは本当に同じブラウザで複数のセッションを維持することは困難になります.次に、例のような複雑な回避策が必要ですproxy servers .

CONS : URLリンクはしばしばユーザーによって共有されます、そして、彼らはURLが機密情報を含むことを知りません.彼らは、彼らのセッションキーを例えばフォーラムまたは電子メールで掲示することができました、そして、キーが有効である間、それにアクセスする誰でもセッションをハイジャックすることができます.あるいは悪意のあるユーザが被害者に、自分の有効なセッションキーを使って準備されたURLを送信し、セッションを引き継ぐSession Fixation Attack この問題を解決する一つの方法は、キーごとの接続を同じIPアドレス指定ネットワークに制限することです.

全体のトラフィックが暗号化されない限り、クッキーやURLセッション処理は安全ではないことに注意すべきです.そうでなければ、いずれかの方法は完全に公共のネットワークでは、例えば、トラフィックを傍受している誰でも読めるようになります.いずれにせよ、セッションキーの妥当性検査を実装する必要があります.
それで、質問は「クッキーがURLセッションキーより安全ですか?」明確に“それに依存する”と答えることができます-任意のケースでは、あなたがやっていることを知っている必要がありますし、セキュリティの側面を念頭に置いている.多くのセキュリティホールは、アーキテクチャ自体からではなく、misconfigurationと怠慢から来ます.
もちろん、両方とも行うことができます:URLセッションプラス認証クッキー.これは実際にはかなり一般的な慣例です.そして、Picolispでこれを行う方法を後のポストに示します.
今私たちのセッションが確立され、我々は最終的にPicolispのGUIフレームワークで再生を開始することができます!しかし、オブジェクトやクラスについての知識が必要です.

ソース
https://software-lab.de/doc/app.html
https://software-lab.de/doc/httpGate.html
https://en.wikipedia.org/wiki/Session_fixation
https://security.stackexchange.com/questions/14093/why-is-passing-the-session-id-as-url-parameter-insecure
https://owasp.org/www-community/attacks/xss/