元税理士受験生、プログラミングをする

1990年生まれド文系プログラマーの軌跡

【徳丸浩氏 特別講演】若手エンジニアのためのセキュリティ講座 感想

サポーターズcolabで開催された【徳丸浩氏 特別講演】若手エンジニアのためのセキュリティ講座に参加しました。

自分用に要点まとめました。

【徳丸浩氏 特別講演】若手エンジニアのためのセキュリティ講座

侵入されるWebサイトとは

Webサイトへの侵入経路は大きく分けて2つ

  • 管理用ツールの認証を突破される
  • ソフトウェアの脆弱性を悪用される

脆弱性とは何か

一言でまとめるとバグ

悪用可能なバグの例

悪用可能な設定不備の例

  • デフォルトのパスワードのまま放置している
  • パスワードとして「password」を設定している
  • 任意のメールを中継する設定(オープンリレー)

徳丸先生が以下の事象について少し言及

IoT機器がマルウェアに感染する元凶は「Telnet」~横浜国大・吉岡克成准教授

Webサイトに対する侵入事件のトレンド

SQLインジェクションが対策されていると下記が台頭

セキュリティのイタチごっこにばかり目がいっていると、大きな脆弱性を見逃すことがあるとのこと。

脆弱性を防ぐためには

責任と契約について ~ウェプアプリケーションの脆弱性の責任は発注者か開発者か~

発注者に責任というのが主流のよう

ただし、判例があるわけではない

しかし、最近(2015年)判例が出ました!!とのこと

徳丸先生がいってた判例はこれの模様

2015年に徳丸先生が言及しています。

SQLインジェクション対策もれの責任を開発会社に問う判決

800万円の案件に対して、2262万円の損害賠償の支払いが確定しました。

経営者からしたら、これはつらいなぁ。。。

若い人は契約は興味は人がほとんどだが、契約の賠償額の限度額を設定して身を守るべき。(青天井契約にしない)

SQLインジェクションが"債務"である理由

経済産業省から注意喚起の文章が出ているので、それを遵守すべき

徳丸先生の当事件の感想

発注者も毎日「admin」「password」と入力してコンソールに入って、何も思わないのか

現在の風潮として「SQLインジェクション」対策は、最低限レベルとの見方もできる。

EC CUBEを用いたSQLインジェクションの実演

個人情報が表示されないページに対しても、SQLにはUNION、副問い合わせを用いれば、簡単にデータベースのスキーマがわかるので無対策の状態で放置しない。

セキュリティ対策

一番安価なセキュリティ対策は、セキュリティ専門家のtwitterアカウントをフォローすること

速報は、ここで検知できそうですね!!

Webアプリケーション脆弱性診断の方法

ツールにて脆弱性を検知すると、数が多いので、それを直すだけでも大変。

Webアプリケーションの脆弱性の手動検知の実演

EGセキュアソリューションズ株式会社の入社試験では、テストアプリケーションの脆弱性を発見するテストをやるそうです。

ここで繰り返し徳丸先生がおっしゃっていたのですが、セキュリティ未経験者でも、勘のいい人は脆弱性の兆候を読み取る。知識ではなく、そういう結論を出す人が欲しいとのことです。

脆弱性診断は仮説-検証の繰り返しだ

挙動は以下の3つに分類される

  • 正常:この診断文字列からは何も言えない
  • グレー:怪しいけど脆弱性とは言い切れない
  • 脆弱性の疑いが濃厚:脆弱性が検出された可能性が高い

キャリアについて

セキュリティエンジニアを将来の夢にしているのですが 現在高2なのですが現在大学…

この質問を例に、徳丸先生の見解をおっしゃっていました。

結論しては

  • 情報工学」「計算機工学」基礎が大事
  • そのためには専門より大学に行くべき
  • 高いところに行くには、とにかく基礎が大切
  • 母国語の「ロジカルシンキング」「言語コミュニケーション能力」が大切

ここのコミュニケーション能力定義は、相手の知識に合わせたコミュニケーションをする(専門外の人に対しては、専門用語を使わない。逆に、専門の人達には、専門知識のラインを設定する)

ネットには速読を勧める記事が多いが、徳丸としては精読を勧める

ここは僕も、ここには賛成です。

ということで、情報工学の基礎本を読み漁ります。

正直なところ、大学にいって基礎から情報工学を学びたいです。

徳丸先生自身について

徳丸先生は20代前半はニートだったそうです。

ちょっと親近感が湧きます。

縁故採用で京セラに入社して、コンパイルの実装に興味を持地、コンパイルの作り方の本を10冊ほど読んでコンパイラを作ったそうです。

なぜ独立・起業したか?

2007年(当時47歳)に独立を真剣に考える

京セラはハードワークで、執筆がしんどい

独立の課題と解決策

受注の価格獲得と、家族(家内)の説得

飛び込み営業とか無理。。。

解決策

前職(KCCS)に技術顧問として残ることを上司から提案され、収入の6~7割を確保

家で仕事するから、子育てもできるので家事の負担を減らせる。

とにかく運がよかった

独立・起業するには

営業力

若手エンジニアに向けて

コンパイラを作ってよかったこと

  • コンピューターサイエンスの基礎をしっかり学べた
  • 「本に書いてないこと」については、自分の頭で考え抜くことで、問題解決能力が身についた
  • 勉強は「車輪の再発明」をどんどんしよう

なぜ多くのプログラマFizzBuzzが書けないか?

コピペプログラマーを脱しよう

プログラマ35歳定年説を超えて

  • 馬力にものを言わせている開発者は、その馬力が衰えてくる
  • 新技術習得についていけない
  • プログラマのままだと給与が上がらない

解決策

  • 馬力に頼らなくても済む技術力を若いうちから身につけておく
  • 新技術も、基礎が入ればだいぶ楽になる
  • 給与は、転職か独立で
  • 40代になると、厄年とか更年期とかいろいろ出てきますが、いつまでもは続かないので一時的なスランプだと思ってやり過ごしましょう

Q&A

Q.情報学部出ていない人はどう勉強すればいいですか?

A.学問に王道なし

東京には図書館に技術書がいっぱいある。

本は、合う合わないのフィット感が大分違う。

なので図書館の本で試すことが大事!!

ネットの記事はちょっと。。。。

Q.仕事の中で、これが大変だったかとかありますか?

A.そういうことも過去にあったが、苦にしないように考えている。

心配してもしょうがないこと(自分でどうにかできる範囲を超えていること)は、考えない。

Q.パスワードの脆弱性の対策としては何がありますか?

パスワードは、これが悪いとかはない

根本的な対策は難しい

脆弱性を前提にビジネスを組み立てる。

Q.ユーザーの立場でパスワードを管理する方法

「Last Pass」というパスワード管理ツールを使っています。

情報漏洩が過去に発生しましたが、パスワード悪用が一度もされていないからです。

LastPass

パスワードの使い回しをするぐらいなら、ブラウザに覚えさせるのもありです。

徳丸先生から20代エンジニアに向けて

プログラムが大好きだったけど仕事にするかは迷いました。

好きな仕事とセットで嫌い仕事も考える。

どんな仕事も嫌いな仕事は一部ある。

好きな仕事と嫌いな仕事の配分が大切

感想

僕も一生この業界にいたいので、当面は基礎技術の習得に費やしていこうと思います。

図書館も活用します!!

サポーターズさんのオフイスが綺麗でした。

10月から務める予定の会社の目の前なので、ここで勉強会があったら、また行きたいです。

# WEB DB PRESS 100 「完全HTTPS化」 感想・まとめ

はじめに

WEB DB PRESS 100 「完全HTTPS化」 感想・まとめ

1,2章のみです。

汎用的な項目のみをまとめてあります。

HTTPSとはそもそも何か

HTTPSは、みなさん同じみのHTTPによる通信をSSL(Secure Soke Layer)あるいはTLS(Transport Layer Security)によってより安全な通信とするための仕組みです。

HTTPSでは公開鍵暗号を用いて、Webサーバーにあるサーバー証明書をWebブラウザにインストールされているルート証明書で検証します。その上で共通鍵暗号の鍵を生成し、公開鍵暗号を使ってWebサーバーと鍵交換を行います。

利用者がHTTPかHTTPSのどちらで通信してるかを判定するには、ブラウザのアドレスバーが「保護された通信」かそうではないか確認するばいいので、一目瞭然ですね。

なぜ完全HTTPS化するのか

これまで

HTTPSはログインや登録情報の参照など、いわゆる個人情報や認証情報を扱う箇所のみに使われていました。 その理由は、データ量増加やHTTPSの処理負荷などオーバーヘッドが大きかったことが考えられます。

企業のコーポレートサイトだと、トップページはHTTPなのに、質問ページだとHTTPSなんてことよくあります。

入力フォームがあるのに、HTTPS化されていない企業のサイトは、その会社全体のセキュリティ意識の低さが体現されてます。

これから

サービスをよりセキュアにするという目的

HTTPSの利用を考えるにあたりまず思い浮かぶ利点は、「通信を暗号化できる」そして「通信先を認証できる」ことでしょう。

情報の重要度に関わらず、全ての入力フォームをHTTPS化することで、情報の安全性の選別が必要無くなります。

OS、ブラウザ、検索エンジン等のプラットフォームの進化に対応する目的

Chorome56でリリースされた、HTTPページにログインフォームが表示されている場合に「保護されていない通信」という警告を出す機能は、多くのHTTPページでログインのモーダルを表示していたクックパッドにも影響を及ぼす変更でした。

たまに、HTTPS化されてないサイトにアクセスすると、赤い画面で警告が出ますよね

あれは心臓に悪い

Googleは検索ランキングに置いてHTTPSの利用有無をランキングアルゴリズムに利用することを発表しています。

ここ最近、はてなブロガーの間でも話題になってました。

アクセス数落ちるし

開発のしやすさを考慮して

(クックパッドの例として)HTTPSが必要な箇所全てに、HTTPSを必須化する共通のロジックを書く必要がありました。これでは、本来HTTPSであるべ画面とそうでないなどの事故が起きやすくなってしまいます。

ソースコードでURL指定してる箇所の修正って地味に面倒なんですよね

新しい技術に対応

新しいWebの仕組みは、その多くがHTTPSであることを前提としています。

最近の技術はHTTPSを前提に実装されています。

導入するまでのロードマップ

組織内での協力を得る

組織内で実践する場合はあらかじめ完全HTTPS化を宣言するなどして、多くの方の協力を得ることが重要です。なぜなら、完全HTTPS化は単純にURLが"HTTP://“から"HTTPS://"に変更されるだけではなく、コードの修正やユーザー体験の変化、壊れている箇所がないかのチェックなど様々な影響を及ぼす可能性があるためです。

トップダウンで、意識共有していかなければいけない問題です。

意思決定者が、なんのためにHTTPS化するのかを社内に浸透させて取り組まなければならないが、その意思統一が難しそう。

証明書の選び方

Webサービスに置けるHTTPS(TLS)通信には適切な公開証明書が必要です。「適切な」というのは、主に以下の要件を満たすことを指します。

・多くのブラウザが信頼する認証局から署名されている

・示したい情報を含められる認証方式が使われている

・安全な署名アルゴリズムが利用されている

公開鍵証明書は、HTTPS(TLS)を再構築する上で非常に重要な要素です。証明書そのものは検索エンジンで「SSLサーバー証明書」などと検索すれば販売しているサービスを多く見つけることができますが、それぞれの証明書が一体どういう特徴、意味を持つのかを押さえた上で利用する証明書を決めましょう。

SSLサーバ証明書の料金比較と選び方総まとめ

証明書の選び方でのポイントは、箇条書きにすると下記の通り

  • ブラウザ対応率
  • 有償無償のどちらか
  • 認証方式について
  • 署名アルゴリズム

最後に

自分はインフラの部分の知識が弱く、本特集の後半部分のリリース後の運用、影響の部分は まだ、文章にして書き残さなくてもいいかなーと思っています。

必要な時期がきたら、本棚からこの号を引っ張ってきて見返します。

プロになるためのWeb技術入門 感想 読書感想

はじめに

Web業界に転職して、そろそろ1年が経過します。

今まで勉強した知識にどの程度抜け漏れがあるのか確認のために、今更ながら「プロになるためのWeb技術入門」を読みました。

改めて理解が促進した箇所、新たな発見があった箇所を列挙します。

なお、私の頭脳のワークスペースの都合上、書籍の前半部しかまとめられてないです。

プロになるためのWeb技術入門

リソースの位置を示すURL

URLの仕組みは、なんとなく使っているので、改めて復習しました。

URLは、ブラウザにアドレスバーに打ち込む文字列です。

インターネット上のコンテンツを一意に指定するための仕組みが「URL(Uniform Rsource Locator)なのです。

日本語に訳すと「統一資源位置子(とういつしげんいちし)」となります。

http :// /www.littleforest.jp / webtext/index.html
スキーム ホスト名 パス名

パーセントエンコード

https://www.test/index.php?name=%E3%83%86%E3%82%B9%E3%83%88

インターネットサーフィンをしてるとURLに「%」が混じることがありますよね

URLは全角文字は使用できないので、ブラウザ側がサーバーでも読み取れる文字にエンコードしてくれます。

これが「パーセントエンコード」です。

スキーム

そもそもhttpsとは何なんか最初のうちはよくわかりませんでした。

スキームは、リソースを取得するための方法を表します。Webアプリケーションにえいては、ほとんどの場合「http」となります

スキーム名 説明
https 暗号化されたhttp通信を表すスキーム
mailto 電子メールの宛先を表すスキーム
ftp FTPプロトコルによる入手を表すスキーム
file ファイルシステム中のファイルやディレクトリを参照するためのスキーム

業務では、httpsftpはよく触れる印象があります。

URLとURIの違い

他のWeb技術の基礎本を読んでいるときに、URLという単語という単語がほぼ登場せず、代わりにURIという単語で使われていることがあります。

URLとURIの違いはなんでしょうか。

URIは、URLをより拡張した概念として、URI(Uniform Resource Idenrifier)が考え出されたのです。

URIとは、URLに加えて「URN(Uniform Rsource Name)」を合わせたものを指します。

URNはインターネット上に存在する名前を一意に識別するために用意されたものです。

URLの場合は、ホストが移動すると移動先のURLを知らないとアクセスできなくなります。

URNは、このようなリソースの移動に関しての問題を解決するために、インターネット上に存在するリソースに対しては統一的な名前を決めようと考え出されたものです。

例えば、「nrn:itif:rfc:2616」は、HTTP1.1のRFCに対するURNです。この文書が物理的にどのような位置に存在しようと、同じURNで指し示すことができるというわけです。

現状ではURNはあまり利用されておらず、実質的にはURIもURLもほぼ同じ意味で扱われています。

混乱の元はURIとURLもほぼ同様の意味で使用されているため、なぜ2種類もの呼び方があるのか理解できないことです。

このように背景を理解してしまえば、理解しやすいですね。

Webベンチャーで働いている人に、あまり馴染みのないサーブレットJSP

PHPRubyでアプリケーションを作っていると、Javaに対してあまり馴染みがありません。

しかしJavaエンタープライズでのWeb開発で使用されている言語、歴史的変遷だけでも知っておくのがいいかと思いました。

サーブレットの誕生

Webが普及しCGIが一般的になると、新たな問題が生まれました。

1つはPerlの仕様による問題、もう一つは多数のリクエストによるアクセス負荷の増大する問題です。

Java自体はWebアプリケーションのために開発された言語ではありません。しかし、Webアプリケーションは当時企業に置けるシステム開発でも主流になりつつありました。

そこで、JavaEE(Java Enterprise Edition)の一部として「サーブレット(Servlet)」というWebアプリケーション開発をサポートするため目の機能が供給されるようになったのです。

サーブレットJavaで作られたHTMLなどのWebコンテンツを生成するためのプログラムのことで、CGIを経由して起動されるPerlC言語Java版に相当します。

サーブレットは基本的にCGIと同じ考え方ですが、コンテンツを生成する言語がJavaであり、オブジェクト志向のサポートによって大規模アプリケーションの開発に向いていることと、Webサーバーと同じプロセスの中でコンテンツを生成するプログラムが動作するため、CGIのように新たなプロセスを毎回起動する必要がなく、比較的高速に動作するということが利点でした。

Javaの優れた特徴をWebの世界に持ち込み、発展させたということですね。

ただJavaエンタープライズ要素が強いので、なかなか個人開発では使用する機会がないです。

サーブレットのコードの例はこんな感じです。

mport java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class Calc extens HttpServlet {
    public void doGet(HttpServletRequest request,
        HttpServletResponse response)
        throws ServletEception,IOException {
        // コンテキストタイプの設定
        response.setContentType("text/html;charset=Shift_JIS");

        // HTML出力の準備
        PrintWriter out=response.getWriter();

// HTMLの出力
    out.println("<html><head>");
    out.println("<title>Calcurator</title>");
    out.println("</head><body>");
    out.println("<p>1000円の税込み価格 ="+ (1000 * 1.08) +"円</p>");
    out.println("</body></html>");

// HTML出力の完了処理
out.flush();
out.close();
    }
}

今見ると可読性が悪いですね。

HTML部分を追うのに一苦労です。

サーブレットのコードは、レガシーPHPに通づるものがあると考えています。

サーブレットの弱点を改善したJSP(Java Server Pages)の誕生

サーブレットの弱点は、画面デザインの変更が初制するたびに、プログラムの変更が必要になること。

さらに、Javaソースコードの中にHTMLが点在するため、可読性が悪いことです。

この弱点、ノンフレームワークPHPプロジェクトに類似する部分がありますよね

これを解消したものがJSP(Java Server Pages)です。

先ほどのサーブレットソースコードJSPに置き換えます。

<html>
<head>
<title>Calcurator</title>
</head>
<body>
<p>1000円の税込価格 = <% out.println(1000 * 1.08); %> 円</p>
</body>
</html>

これってRailsとかCakePHPのview部分に似てますね。

用途の近しい技術は類似していくんですね。

感想

最初は自分用のまとめにしようと思ったのですが、段々熱が入り、少しでもまとめようという気持ちが出てきました。

しかし、読み手を考えると、書籍の感想のまとめは難しく、結局前半部分しかまとめられませんでした。

後半は、何か別の書籍とミックスしたいと思います。

GitHubにpushしたら、CircleCIで自動的にはてなブログに投稿する仕組みを作った。

仕組みは後日解説、とりあえずできて嬉しい!!!

https://github.com/yamakawa00/blog

S3にアップロードしようと思ったら、時計がズレていたので失敗した。

S3にアップロードしようと思ったら、時計がズレていたので失敗した。

環境

S3にアップロードしようと思ったら失敗した。

S3にアップロードしようと思ったら、以下のメッセージが返ってきました。

The difference between the request time and the current time is too large.

日本語訳:リクエストサーバーとS3の時間のズレが大きすぎる

同様の問題の解決記事

[Rails] 時計のズレが原因でS3への画像アップロードが失敗した

原因は、S3のサーバー時刻とWebサーバー時刻にズレがあったため

まずntpdateで自分のサーバーの時刻と日本標準時間を同期します。 Webサーバーは、vagrantを使用しています。

$ sudo ntpdate ntp.nict.jp
 6 Aug 14:02:10 ntpdate[7681]: adjust time server 133.243.238.244 offset 0.003161 sec

## ntpdateとは

ntpdateコマンドでは、日付と時刻をNTPサーバーと同期するコマンドです。

ntpdate - 日付と時刻をNTPサーバーと同期 - Linuxコマンド

以下ntpd関連資料

NTPサーバー構築(ntpd)

14.4. ntpd の起動と動作確認

ntpdデーモンの設定を変更したので、ntpdを再起動しましょう。

$ sudo /etc/rc.d/init.d/ntpd restart
ntpd を停止中:                                             [  OK  ]
ntpd を起動中:                                             [  OK  ]

これでOK!!