7年ぶりのブログ更新です。このサイトは長く ASP.NET Core で動かしていましたが、このたび全ページを静的HTMLに作り直しました。その作業で一番考えさせられたのが「問い合わせフォーム」でした。サイト制作では当たり前のように付ける部品ですが、実はサイトの中で一番危ない場所です。今日はその話を書きます。

フォームはサイトで一番狙われる場所

WordPress サイトへの侵入経路は、本体よりもプラグインが大半を占めます。その中でも問い合わせフォームのプラグインは特別です。ほぼすべてのサイトに入っているからです。定番のフォームプラグインは数百万サイトで使われており、ひとつ脆弱性が見つかると、その数百万サイトが同時に攻撃対象になります。攻撃側から見れば、フォームは「外部の入力を受け取ってサーバーで処理する」機能そのものなので、探す価値が最も高い入口です。

スパム対策は「防御側だけがお金を払う」構造になりがち

フォームを置けばスパムが来ます。長年の定番だった CAPTCHA(画像認証)は、AI が実用レベルで突破できるようになりました。Google の reCAPTCHA は従量課金の Enterprise 版へ誘導が進んでいますが、これは判定(アセスメント)ごとの課金で、防御に成功した判定にも課金されます。つまり攻撃されるほど請求が増える。ボットは無料で殴り続けられるのに、防御側は殴られるたびに支払う——この構造自体がおかしいと思いませんか。

自動返信つきフォームは「踏み台」になる

意外に知られていない問題がもうひとつあります。メールアドレスを入力すると自動返信が飛ぶフォームは、他人のメールアドレスを大量に入力されると、迷惑メールの発信源になります(メールボム)。自分のドメインの送信評価が下がり、本来のメールまで届かなくなる。対策には送信頻度の制限や、制限に達しても攻撃側に悟らせない応答設計が必要ですが、そこまで作り込まれた問い合わせフォームはまれです。

放置されたフォームが一番危ない

そしてサイトは、作ったあとに放置されます。更新が止まった WordPress のフォームは、脆弱性が公表されても直されないまま公開され続けます。この「放置された WordPress に何が起きるか」は、当サイトの漫画の新シリーズ「WordPressの危険性編」で描いていますので、あわせてどうぞ。

それで、どうしたか

このサイトが選んだ答えは、公開サイトから動的な処理をなくすことでした。全ページを静的HTMLにすれば、フォームの脆弱性も、サーバーの侵入も、そもそも実行されるプログラムが無いので起きません。

問い合わせは、メールで受けることにしました。フォームと違って送信者の実アドレスで届くので、本人性の確認にもなります。スパムは受信側のフィルタで防ぎます——これは送信側(フォーム)の防御よりずっと枯れた、実績のある技術です。

静的サイトの配信は Cloudflare Pages の無料枠で足ります。デプロイ用には cf-publish という小さな CLI を作って PyPI に公開しました(pip install cf-publish)。ビルドしたフォルダを1コマンドで公開でき、失敗してもロールバックできます。このサイトも同じ方法で公開しています。

まとめ

問い合わせフォームは「無料の小機能」ではありません。継続的な防御・監視・スパム対策のランニングコストを伴う、サイトで一番危ない機能です。サイトを作る(作り直す)ときには、一度立ち止まって考えてみてください——そのフォーム、本当に必要ですか。メールではだめですか。

Bootstrap 4 Alpha 6 が1月6日に公開されました。今回のバージョンでかなり完成に近づいたと思うので、テスト的に使ってみました。次は、Beta になる予定で、残っている Issues の数もそれほど多くないので、基本的な所での変更はあまりないだろうと思っています。

自分の場合は、Visual Studio 2015 を使っていて ASP.NET Core で Web アプリケーションを作ることが多いので、最初に Visual Studio の ASP.NET Core Web Application のテンプレートを使って試してみました。

Bootstrap 4 に更新するためには、bower.json を以下のように変更します。bootstrap のバージョンを変更し、ツールチップの表示に Tether という JavaScript のライブラリーを利用するため、そのライブラリーを追加するだけです。

{
  "name": "asp.net",
  "private": true,
  "dependencies": {
    "bootstrap": "4.0.0-alpha.6",
    "jquery": "3.1.1",
    "jquery-validation": "1.14.0",
    "jquery-validation-unobtrusive": "3.2.6",
    "tether": "1.4.0"
  }
}

インストールするだけであれば簡単なのですが、実行させてみると完全にレイアウトが崩れてしまいます。Ver3 から Ver4 への変更は影響がかなり大きいことがわかります。

どのような修正が必要になるのかについては、そのテンプレートを、取りあえず動くようにしたものを GitHub の方に公開していますので参考にしてください。Navbar や Carousel にもかなり修正が入っています。

それで、公式ドキュメントを結構真面目に読んでいます。英語がそれほど得意でないので、前回のブログで紹介した「Google ウェブサイト翻訳ツール」プラグインをつけたドキュメントのページが結構役に立っています。

それらの作業をして、公式ドキュメントの Migrating to v4 を読んだところでは、Ver4 の特徴は、HTML5、CSS3 の機能をフルに活用するようになったということのようです。

自分としては、Bootstrap 4 は以前よりかなり良くなっていると思うので、積極的に使っていきたいです。でも、class 名が結構変わっているので、既存のWebサイトを Bootstrap 4 にバージョンアップしようとすると修正箇所が多くなるので、手間を考えると少し憂鬱ですが、時間をかけて更新していくつもりです。

なお、Ver4 の主な変更点は、以下のようなところです。

• IE8 と IE9 のサポートの廃止
• Flexbox によるレイアウト
• Less から Sass へ
• 標準のフォントサイズは 16px
• 使う単位を px から rem に変更
• ブレークポイントに576pxを追加

Bootstrap 4 Alpha が最初に公開されたのは、昨年の8月19日です。それから1年4ヶ月を経過しましたが、まだ Alpha 5 という状況です。開発に非常に時間がかかっていますが、最近になってやっと開発が加速しているようなので、自分もテストに使い始めました。

Bootstrap 4 Alpha のドキュメントは当然英語しかないのですが、Google翻訳にニューラルネットワークが導入されて精度が大幅に上昇しているので、Bootstrap 4 のドキュメントに「ウェブサイト翻訳ツール」プラグインをつけてみました。Bootstrap のドキュメントは、GutHub で CREATIVE COMMONS で公開されているので、著作権の問題はないので以下の URL で公開していますので興味のある方は見てください。

http://bootstrap.pp22.net/

プラグインを追加するだけで、翻訳ができてしまうのは、素晴らしいです。

Google 翻訳は、まだまだ、おかしなところも多いですが、あれば便利というところまではなっていると思います。以前は使い物にならなかった機械翻訳ですが、やっと少しですが実用的になったようです。

Bootstrap 4 の日本語のドキュメントはBootstrap 4 日本語リファレンスという翻訳中のものがあるのですが、現時点では未翻訳の部分が多いし、Alpha 2 ベースです。ドキュメントの翻訳には時間と手間がかかるので、もう Google 翻訳で我慢してもいいように思います。

Bootstrap 4 の開発状況ですが、9月6日に、現行バージョンである Bootstrap 3 の定期的メンテナンスを終了するという発表（Getting to v4）がありました。この状況については、InfoQの「Bootstrap v3の定期的メンテナンスが終了」という記事が参考になると思います。

現在開発中の Alpha 6 では、Flexbox がデフォルトになり従来の float レイアウトはサポートされなくなります（v4 Alpha 6 ship list）。普通に使っているブラウザーで Flexbox をサポートしていないのは IE9 だけですが、IE9 は今年（2017年）の 4月11日に Windows Vista と共にサポート切れになります。

これらの件は、当初の計画とは違うものですが、開発者の負担の軽減ということでは仕方がないことだと思います。そして、Bootstrap 4 の 問題（Issues） が順調に解消され始めています。近いうちに Alpha 6 が公開され、その次は Beta です。完成も見えてきたように思います。

この Webサイトは、Umbracoで作っていましたが、ASP.NET Core（ASP.NET 5）+ .NET Core で作成し直してみました。Umbracoも拡張性が高くて悪くはないのですが、自分でプログラムを書きたい場合には自由度が小さくなるのとデバックの時には重くなるのが欠点でした。それで思い切って、作り直すことにしました。選択肢としては、ASP.NET MVC 5、ASP.NET Core + .NET Framework 4.6、ASP.NET Core + .NET Core の三つでしたが、思い切って NET Core + .NET Core にしてみました。

ASP.NET 5 については、スケジュールが変更され、名称も ASP.NET Core に変更になるということで、RC2 が出る直前になってドタバタしているようですが、実際使っていると問題点があることはわかります。でも、基本的なところはそれほど変わっていないし安定しているので使えないことはないです。

運用を始めたばかりで、切り替えの時に少し失敗してサーバーを止めてしまったこともありましたが、取りあえずは普通に動いています。Ubuntuサーバーの方でもテストしていますが、そちらも大きな問題はなく動作しています。

ASP.NET Core、.NET Core については、最近マイクロソフトから以下のブログが出て、方向性がよくわかるようになったと思います。

ASP.NET 5 is dead - Introducing ASP.NET Core 1.0 and .NET Core 1.0

An Update on ASP.NET Core and .NET Core

Porting to .NET Core

ASP.NET Community Standup – February 16, 2016

Porting MSBuild to .NET Core

コンパイラーが DNX から CLI に変更になるというのは賛成です。このサイトの発行時のファイルサイズは、約300MBぐらいで、その内runtimesが106MB、packagesが190MBです。runtimesの分は、ホストのOSにインストールされたランタイムを使う必要がなくなった代わりに必要になるもので、どんな小さなアプリにでも必要になります。packagesの分が大きくなっているのは、.NET Core だけでなく下の図のように Windows Phone 8 や Xamarin のものまで含まれているためです。Webサーバに関していえば、これぐらいのファイルサイズでも我慢できなくはないのですが、コンソールアプリケーションで 100MBというのはちょっと大きすぎだと思います。AOT（事前コンパイラ）をしてファイルサイズも減らして欲しいし、最初の起動時間も短縮して欲しいと思うし、コンソールアプリケーションだと、ネイティブコードにコンパイルして欲しいところです。

.NET Core を使う上での支障は、ライブラリーの対応があまり進んでいないことです。「Porting to .NET Core」に書いてあるように、.NET Core でも System.Data、System.DirectoryServices、System.Drawing、System.Transactions、System.Xml.Xsl、System.Xml.Schema、System.Net.Mail、System.IO.Ports、System.Workflow、System.Xaml で、時間がなくて移行があまりできていないそうです。 そういう状況なので、サードパーティ製のライブラリーの対応状況は悪いです。

現状では、ASP.NET だと、ASP.NET Core + .NET Framework 4.6 という選択肢が現実的だし、UWP の方も windows 10 mobile が殆ど普及していないことや、デスクトップPCでも依然として主力は Windows 7 であることを考えれば、.NET Core を急ぐ必要はないと思います。

しかし、5年後を考えると .NET Core が必要というのは間違いないと思います。また、下の図は、Azure の VM の Linux と Windows の価格です。個人だとこれだけ価格に差が出てくると Linux の方を使いたいと思ってしまいます。それで、これからは、 Linux のことも書いていきたいと思っています。

日本のWebサイト制作では、WordPressが一人勝ちになっています。WordPressは優秀なソフトですが、猫も杓子もWordPressというのは行き過ぎではないかと思います。

ささっとWebサイトを作りたい場合には、Webサービスの方を使ってみた方がいいと思います。代表的なウェブサイトビルダーといえば、以下のようなものがあります。

Wix

デザイン性の高いテンプレートが揃っています。 Google検索で site:wix.com とするとかなりの数の Wix で作成したサイトが見つかります。例としては、久米島ホタルの会のWebサイトがあります。素人でも少し美的センスがあれば、結構見た目のいいWebサイトを作ることができます。PowerPoint を使える人であれば、間違いなくそれなりのサイトは作れると思います。

Weebly

Wix と比べると地味な感じのテンプレートが多くなっています。Wixと違ってHTMLとCSSでフルカスタマイズすることが可能なので、テンプレートに Bootstrapを使うことも可能です。地味な会社サイトを作りたい場合にはWixより適していると思います。Weeblyで作成したWebサイトの例としては、あま り有名なものはありませんが、site:weebly.com で Google検索をすると結構な数のWebサイトが表示されます。例えば、柏まちづくり文化賞というサイトがあります。これぐらいのWebサイトであれば素人でも少し HTML, CSS を勉強すれば作れるのではないかと思います。

Tumblr

映像や画像を多用するサイトとの相性がいいサービスで、今回の漫画「Tumblrでポートフォリオを作ろう（基本編）（１）」で紹介しています。漫画の中で紹介しているGAPのページはTumblrの特徴を上手に使っています。GAPのことをいえば、Pintrestの方にもGAPのページがありこちらの方でもPintrestの機能をうまく使っています。Webデザイナーであれば、WordPressを勉強するのではなくGAPのようなサイトを作るのも一つの方向だと思います。

WordPressは本当に安いの

Wixの有料プランの料金は、下の図のようになっていて、「無制限」の値引き前の価格で年15600円です。

それでも、WordPressユーザーには高いという人がかなりいます。そしてWordPressは無料で安いと言います。でも、WordPress を使えるようになるまでにいくら時間がかかるかの計算をしていないからそういうことがいえるのです。

石垣島ITブートキャンプが1ヶ月間でWordPressの作り方を習得するようです。それでも素人が1人で WordPress で WEB製作をできるようになるのはなかなか難しいようです。その期間の人件費と授業料を考えれば50万円～100万円ぐらいのコストにはなると思います。

また、Web制作を委託にだしてWordPressで作成してもらった場合も同じぐらいの費用が必要になります。それに、WordPressの場合、自社で運用するのが難しくて、年10万以上の運営管理費を制作会社に払っているところは多いと思います。

学習コストを考えると、年1万や2万というのは安いものです。

Weeblyは、本当に日本語フォントがない？

Google で Weebly と検索すると日本語でトップに出てくるサイトでは、以下のように書いてあります。

簡単なレストランのサイトを作ろうとしました。
作ろうとしましたが、断念しました。決定的な理由は簡単に言うと以下です。

• 日本語フォントがない
• モバイル版がいまいち

そのほかは、なかなか素敵です。

これでは、Weebly があまりにも可哀想です。

Weeblyでは、コントロールパネルの「フォントの変更」には確かに日本語フォントはありませんが、CSSを直接編集することにより、日本語フォントもちゃんと使えます。

「デザイン」のパネルを表示すると、「フォントの変更」の下には「HTML/CSSの編集」というボタンが一番下にあって、HTML/CSSを編集できることはすぐわかります。

それをクリックすると、下の図のようにHTMLやCSSの編集画面が表示されます。自分の使ってみたテーマでは、main_style.css がメインのスタイルシートになっていて、そこで、font-familyに日本語フォントを追加していってやるだけです。

それから、モバイル版もいまいちということはありません。レスポンシブルのテーマを使えば、モバイル版はきちんと表示されます。試しにWeeblyでページを作ってみましたが、それほど問題なく表示されています。

ブログの筆者は、わざわざレスポンシブルでないテーマを使っていますが、その場合は、PC版とモバイル版のヘッダー画像が別のものになるというのが仕様のようです。その場合でも、同じヘッダー画像にしようと思えば、PC版もモバイル版もヘッダーなしを選択して、自分でヘッダーを作れば大丈夫です。

ブログの筆者が言うようにWeeblyは「なかなか素敵」です。