  |
はてなキーワード: XSS脆弱性とは
まじな話をすると、N予備校のプログラミング入門コースやるのがオススメ。
一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。
月額1000円だけどしっかり勉強すれば一ヶ月の無料期間中に終わると思う。
もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラムで講師曰く去年はこれで二人エンジニア就職を決めたらしい。
内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職に必要な環境構築やセキュリティまでみっちりやる。
で講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。
↓みたいなことが学べる
----
Web ブラウザとは (Chrome, デベロッパーコンソール, alert)
はじめてのHTML (VSCode, HTML, Emmet)
さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)
HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)
はじめてのJavaScript (JS, ES6, エラー)
JavaScriptでの計算 (値, 算術演算子, 変数, 代入)
JavaScriptで論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)
JavaScriptのループ (ループ, for)
JavaScriptのコレクション (コレクション, 配列, 添字, undefined)
JavaScriptの関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)
JavaScriptのオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)
はじめてのCSS (CSS, セレクタ, background-color, border)
CSSを使ったプログラミング (transform, id, class)
Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)
診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)
診断機能の組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)
ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)
LinuxというOS (VirtualBox, Vagrant, Ubuntuのインストール, OS, CUIの大切さ)
コンピューターの構成要素 (ノイマン型コンピューター, プロセス, lshw, man, ps, dfの使い方)
ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)
標準出力 (標準入力、標準出力、標準エラー出力、パイプ、grep)
vi (vimtutor)
シェルプログラミング (シバン, echo, read, 変数, if)
通信とネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)
サーバーとクライアント (tmux, nc, telnet)
HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)
GitHubでウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)
イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)
GitとGitHubと連携 (git, ssh, clone, pull)
GitHubへのpush (init, add, status, インデックス, commit, push, tag)
Gitのブランチ (branch, checkout, merge, gh-pages)
Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)
集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)
アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)
ライブラリ (ライブラリ, パッケージマネージャー, npm)
Slackのボット開発 (slack, mention, bot)
HubotとSlackアダプタ (hubot, yo)
モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)
ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)
同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)
例外処理 (try, catch, finally, throw)
HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsのイベントループ, リスナー)
HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)
HTMLのフォーム (フォームの仕組み, form, input)
HerokuでWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)
認証で利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)
Cookie を使った秘密の匿名掲示板 (Cookie, Set-Cookie, expire)
UI、URI、モジュールの設計 (モジュール設計, フォームのメソッド制限, リダイレクト, 302)
フォームによる投稿機能の実装 (モジュール性, textarea, 303)
認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)
データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)
トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)
削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)
管理者機能の実装 (Web サービスの管理責任, 管理者機能の重要性)
デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)
脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)
XSS脆弱性の対策 (XSS, 適切なエスケープ処理, リグレッション)
パスワードの脆弱性の対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)
セッション固定化攻撃脆弱性の対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)
より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)
安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)
Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)
ExpressのAPI (app, Properties, Request, Response, Router)
GitHubを使った外部認証 (Passport, OAuth)
テスティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)
継続的インテグレーション (CircleCI)
クライアントのフレームワーク (Webpack, Chrome 以外のブラウザでもES6)
DOM操作のフレームワーク (jQuery, jQueryアニメーション, this)
AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)
WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)
RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)
テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)
インデックス (インデックス, 複合インデックス, Bツリー)
集計とソート (SUM, COUNT, ORDER BY, GROUP BY)
「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計、モジュール設計、MVC)
認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)
予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)
予定とユーザーの一覧の表示 (非同期処理, Promise, then)
出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)
出欠とコメントの更新 (Promiseチェイン, リファクタリング)
ご相談ありがとうございました。
「タイトルは釣りです」は時によって逆効果ですが、回答させていただきます。
また悩み相談のタイトルは、毎回、そのお悩み本文の中から特徴的なフレーズを切り出して使わせていただくのですが、今回は言うまでもなくあの部分を使わせていただきました。
はてなブックマークだけを話題にあげるのはかわいそうです。主にlive doorクリップとかが特にかわいそうです。話題にもされず。
さてしかし、彼の気持ちは分からないでもありません。
自分自身、はてブに限らず、増田やハイクなどで釣り記事を書くと、その反応が気になってしかたなくなります。
頭の中で、直前に書いた内容を何度も何度も反芻し、
「うふふふ…。自分でもあんなコトを書くなんて…。みんなどう思うかなぁ…。うふふふふふふ」
みたいな感じです。
冷静に考えると、あらためて変態だと思います。
さて、しかしだからといって、目の前にいるあなたのことが嫌いとか、存在感が薄いとか、どうでもいいとか、二次元以下とか作画崩壊とか、そんなことはまったくありません。この言葉によってさらに安心できなくなったかもしれませんが安心してください。
いずれにしても、あなたのことはあなた。
そして、はてなブックマークのことは はてなブックマークとして、並行して楽しんでいるわけです。
完全に はてなブックマークのことしか考えていなければ、あなたとすら会わず、部屋にこもりきりでネガコメってるはずです。ここまでくると記事をプリントアウトして医者にGO!です。すなわちまだ彼は軽いと判断できます。
ですのでそこまで心配することはないとは思いますが、もしそれでもさらにあなたをハックさせたいと思うのでしたら、接続の前に、あなたのポートを全て開放してから臨むというのはいかがでしょうか。
「あのタイトル欄についてだけど、確かにXSS脆弱性あるよねー！」
「あれ、スクリプト埋め込んだ！」
など、はてなの話題についてidコールで触れれば、彼もあなたをハックしたくなるはずです。
彼にしてみれば、「俺のスクリプトのインジェクションもしたい、はてブについての反応も気になる」わけですから、あなたがどちらも満たしてくれるなら、それに越したことはないわけですし。
ただ、彼のブコメ内容と真っ向から反対するdisりなどはいけません。
「こいつは理解してくれていない。他のお気に入りさんなら…」
と思い、プライベートモードの世界に沈んでしまいます。気をつけましょう。
解決策になっているか分かりませんが、とにかく はてなを倒産させる以外にできる方法としては、ベストなのではないかと思います。
ちなみに はてなのプロフィール中に「アンテナ」というものがありますが、あれを見るたびに、ストーキングされている自分を思い描きます。
昼間に何個もの活動があったら、「あぁ、きっとみんな私のことニートだと思ってる」みたいな。
せっかくなので、ここ2年ほどのさくらインターネットiDC移転を中心に、わかる範囲ではてなサーバ変遷の歴史をまとめてみようと思う。
> 59.106.108.68: mobile.hatena.ne.jp.
> 59.106.108.69: f.hatena.ne.jp.
> 59.106.108.70: rimo.tv.
< 125.206.202.66: mgw.hatena.ne.jp. < 61.196.246.69: b.hatena.ne.jp. < 61.196.246.70: b.hatena.ne.jp.
> 59.106.108.71: mgw.hatena.ne.jp. > 59.106.108.72: b.hatena.ne.jp.
< 221.186.129.148: g.hatena.ne.jp.
> 59.106.108.73: g.hatena.ne.jp.
< 125.206.202.82: search.hatena.ne.jp. < 221.186.129.147: ring.hatena.ne.jp. < 221.186.146.28: a.hatena.ne.jp. < 61.196.246.68: r.hatena.ne.jp.
> 221.186.129.147: search.hatena.ne.jp. > 59.106.108.74: a.hatena.ne.jp. > 59.106.108.75: r.hatena.ne.jp. > 59.106.108.76: ring.hatena.ne.jp.
< 125.206.202.83: d.hatena.ne.jp. < 221.186.129.146: d.hatena.ne.jp. < 221.186.146.29: d.hatena.ne.jp. < 61.196.246.67: d.hatena.ne.jp.
> 59.106.108.77: d.hatena.ne.jp.
> 59.106.108.97: d.hatena.com. > 59.106.108.97: hatena.com. > 59.106.108.97: m.hatena.com. > 59.106.108.97: m.hatena.ne.jp. > 59.106.108.97: s.hatena.com. > 59.106.108.97: s.hatena.ne.jp.
> 59.106.108.80: d2.hatena.ne.jp.
d2.hatena.ne.jpで新しいコメント構造の実験を開始しました - はてなダイアリー日記
< 221.186.129.147: counter.hatena.ne.jp. < 221.186.129.147: search.hatena.ne.jp.
> 59.106.108.81: counter.hatena.ne.jp. > 59.106.108.82: search.hatena.ne.jp.
> 59.106.108.78: w.hatena.ne.jp. > 59.106.108.84: h.hatena.ne.jp. > 59.106.108.84: h.hatena.com. > 59.106.108.98: w.hatena.com.
< 221.186.146.27: www.hatena.ne.jp. < 61.196.246.68: screenshot.hatena.ne.jp. < 125.206.202.66: map.hatena.ne.jp. < 125.206.202.66: i.hatena.ne.jp. < 125.206.202.66: graph.hatena.ne.jp. < 125.206.202.66: q.hatena.ne.jp.
> 59.106.108.86: www.hatena.ne.jp. > 59.106.108.87: screenshot.hatena.ne.jp. > 59.106.108.88: map.hatena.ne.jp. > 59.106.108.89: i.hatena.ne.jp. > 59.106.108.92: graph.hatena.ne.jp. > 59.106.108.99: q.hatena.ne.jp.
< ???.???.???.???: auth.hatena.ne.jp.
> 59.106.108.90: auth.hatena.ne.jp.
長いので省略
> 59.106.108.93: rokuro.hatelabo.jp.
> 59.106.108.102: k.hatena.ne.jp.
> 59.106.108.103: favicon.hatena.ne.jp. > 59.106.108.105: img.b.hatena.ne.jp. > 59.106.108.106: bbeta.hatena.ne.jp.
> 59.106.108.93: bottle.hatelabo.jp. > 59.106.108.93: counting.hatelabo.jp. > 59.106.108.93: news.hatelabo.jp.
<body onload="document.frm.submit()"> <form name="frm" method="post" action="http://yutori.2ch.net/test/bbs.cgi?guid=ON"> <input value="書き込む" name="submit" type="submit"> <input name="FROM" size="19"> <input name="mail" size="19"><br> <textarea rows="5" cols="70" wrap="off" name="MESSAGE">てｓｔ</textarea> <input name="bbs" value="news4vip" type="hidden"> <input name="key" value="key" type="hidden"> <input name="time" value="time" type="hidden"> </form>
もちろん、反論もあるだろう。たとえば「Defending PHP」とか。
でも、個人的にはやはり否定側の方が筋が通ってる印象かな。
特に「rubyは初心者に学びやすい(と言われていることが問題である)」という部分に共感する。 rubyは初心者に簡単かもしれないが、初心者による手を抜いたWebアプリケーションは rubyが作られた当初はともかく、現代では害悪ではないだろうか。
cgi.rbならではの理由がないわけではないことはわかる。標準添付されているとか、デプロイが簡単とか。
でも、「標準添付」を一般公開されるWebアプリケーションを開発するためのライブラリとしての利点にするのはもうやめようよ。
追記
「どのライブラリで書いてもおかしなコードを書く奴は書く」という指摘もあった。それは言うまでもない事実ではある。そこには反論しない。
が、本当に問題なのは、世の中には「おかしなコードを書くことを助長するライブラリ」もあるという点だ。で、そういうライブラリにはおおむね「標準添付」というラベルがついている。どういうわけだか。
たぶん、「初心者がおかしなコードを書くのをじゃましない」とかあるいは「初心者っぽいコードを積極的に支援する」から、「標準添付」って呼ばれるんだろう。もしくは「設計者がまだ初心者」とか。
そういうライブラリが存在しちゃいけないとは言わないけど(人に迷惑をかけない範囲で)、ここ半世紀のライブラリの進化をないがしろにするのはもったいないと思うな
