この文章の対象

WEBエンジニアを目指すがが、どれから手をつけたらいいかわからない・・・って人の為のエンジニアライフハッカー的な内容です。

何から最初に手をつけるべきか? まったくの初心者の方

よく一般的にこういう、How Toのような物だと効率よく如何に学ぶかという事がポイントになりますが、そういった意味での最短コースは決まっています。

  • WPでブログを作成(記事作成時に簡単なHTMLなども習得)
  • WPのテンプレートの変更(CSS,JS,PHP FTPなどの操作も)

つまりはWordpressで一通り自由にサイトを作れるようになるのが最短と言えます。
この道を進める理由は、これさえ出来れば個人サイトやブログ運用は難なく出来るようになるからです。

そして第1の分岐点

  • フロントエンジニアに進むか
    • node、トランスパイラなどを駆使して管理しやすいCSS,JSを書く
    • JSのフレームワークを習得し、SPAに近いWEBアプリを作成
  • バックエンドエンジニア、システムエンジニアに進むか
    • PHPフレームワークや多言語(ruby,python,java・・・・)などに
    • サーバ構築、開発テストからデプロイまでを一貫して行う
  • フルスタックエンジニアを目指すか
    • フロント、バックエンドに必要な技術を全て同時に進行していく

ある程度、進むとこういう分岐点にあたると思います。

中には、とりあえずフロントからとか、バックエンドから入る方もいると思いますが、そういった方は一旦Wordpressなり、MovabletypeなりCMSパッケージを使ったサイト作成を一度は経験しておいた方がいいと思います。

そして次の分岐点

問題はここからです。おそらく通常のエンジニアであれば徐々に得意領域が出来てきて、それこそドキュメントなどを参照しなくても色んな事が出来てくると思います。

しかしここが 一番危険なポイントです。

熟練していく事は大事ですが、人間の脳は徐々に新しい物を吸収する力が弱くなります。

例えば日本語に慣れすぎた結果英語の取り組みはかなり難しくなりますよね?

ある程度得意分野を深めつつも、ここから急激に浅く広く知識を広めていく事が大切です。
本サイトのTOPにある、あらゆるカテゴリを習得して行くことをオススメします。

理由は以下の2点です。

  • これからも今のスタンダード技術が、そのまま有り続けるとは限らない
  • エンジニアの基礎体力は学び、活用し続ける事が出来る事である。

という事です。

10年前、20年前と比べ、確実にWEBは進化してきている。

アナログテレビがデジタル放送になったような衝撃がWEBの世界では日々起きています。
一年前の新技術が一年度他の技術に入れ替わっているという事も珍しくありません。

エンジニアがエンジニアとして生きていく為の一番のポイントはこの変わりゆく時代の波に乗って行くことです。

そしてスポーツ選手に必要な 基礎体力向上=ランニングのように

エンジニアに必要な 基礎体力向上=学び続ける力 という事が言えます。

あらためて初期エンジニアに必要な最短スキルアップ法とは?

シンプルに基礎体力の高い人間はスポーツもうまくいきます。

つまり基礎体力を如何に身につけるかがポイントです。

スポーツでの基礎体力向上は同じ事の反復です。しかしエンジニアにおける基礎体力は同じことの反復ではいけません。

毎日のように新しい技術、カテゴリ、分野を習得し続ける事です。

今はネットで全てのWEB技術を学べる時代です。

目安になるかどうか、わかりませんが僕の周りのエンジニアは1ヶ月に最低1つは新しい技術を使いこなすレベルまでに行ってます。

それを普通と言うのなら、2週間に1つ、1週間に1つ、何なら毎日1つ以上新しい技術を習得する事により他の人に比べて格段のスキルアップが望めるはずでうす。

わからなくても予想、予測する

理解に苦しむ技術や概念に出会った時ほどチャンスです。 それらを予想、予測する事は確実に成長に繋がります。

そしてそのうち、新しい技術が出てきた時に「あ、これはあのパターンだな」などと予測がだんだん出来てくるはずです。

日本のことわざに「一を聞いて十を知る」という言葉がありますが、その状態を徐々に体現できるようになってきた時、きっとどんな技術も恐れずに取り込んでいける状態になるはずです。

もし貴方が、同じ技術を数日以上おいかけている場合は、常に新しい物を同時にすすめていけるようにチャレンジしてみてはいかがでしょうか?

脆弱性について

主にウェブアプリケーション、サイトについて


Index

  • A 概要
  • B 脆弱性を自分で体験する診断ツール
  • C 一般的な区分
  • D それぞれの詳細、対策
  • E 補足,未整理

A 概要


B 脆弱性を自分で体験する診断ツール

脆弱性診断ツール OWASP ZAP vs 脆弱性だらけのWebアプリケーションEasyBuggy

Owasp Top 10なども参考に

セキュリティ・脆弱性診断無料ツール・有料サービスの比較と選び方


C 区分

1 認証

  • [ ] 1-1 パスワードポリシー
  • [ ] 1-2 不適切な認証
  • [ ] 1-3 脆弱なパスワードリマインダ

2 承認

  • [ ] 2-1 セッションの推測
  • [ ] 2-2 不適切な承認
  • [ ] 2-3 セッションの固定
  • [ ] 2-4 クロスサイトリクエストフォージェリ

  • [ ] 2-5 補足:Cookieで「secure 属性」を指定 保険的な対策

  • [ ] 2-6 セッションハイジャック

3 クライアントがわでの攻撃

  • [ ] 3-1 クロスサイトスクリプティング
  • [ ] 3-2 コンテンツの詐称

4 コマンドの実行

  • [ ] 4-1 バッファオーバーフロー
  • [ ] 4-2 書式文字列攻撃
  • [ ] 4-3 LDAP インジェクション
  • [ ] 4-4 OS コマンドインジェクション
  • [ ] 4-5 SQL インジェクション
  • [ ] 4-6 SSI インジェクション
  • [ ] 4-7 XPath インジェクション

5 情報公開

  • [ ] 5-1 ディレクトリインデクシング
  • [ ] 5-2 ソース記載による情報漏えい
  • [ ] 5-3 推測可能なリソース位置

  • [ ] 5-4 ディレクトリトラバーサル

6 ロジックを狙った攻撃

  • [ ] 6-1 機能の悪用
  • [ ] 6-2 パス・トラバーサル
  • [ ] 6-3 リダイレクタ
  • [ ] 6-4 不適切なプロセスの検証

7 その他、概念的にまとめた物

  • [ ] 7-1 ヌルバイト攻撃
  • [ ] 7-2 メールヘッダ・インジェクション、メール第三者中継
  • [ ] 7-3 HTTPヘッダインジェクション、HTTPレスポンス分割攻撃
  • [ ] 7-4 スクリプトインサーション

D それぞれの詳細、対策

1 認証

1-1 パスワードポリシー

簡易なパスワードにしないなどのポリシー

1-2 不適切な認証

1-3 脆弱なパスワードリマインダ

パスワードを忘れた場合に、QAなどでログインできてしまうやつ

2 承認

  • 対策コード
// HTTPS限定の物を含む設定
session_name("randamunasuujinadonado"); // A) sessionidを任意の物に変更
ini_set('session.cookie_secure', 1); // B) secureな状態でのみcookieの通信を行う。

//有効期限を設定、例えば1日
$exipires__dd = 60*60*24 ; 
ini_set('session.gc_maxlifetime', $exipires__dd);
ini_set('session.cookie_lifetime', $exipires__dd);
session_start();
  • 補足: session.cookie_secureを設定するとhttp環境ではアクセス毎にクッキーが更新されてしまう。
    https下で使うのが望ましい。

  • 補足: session,cookie それぞれの有効期限の話
    https://teratail.com/questions/33522

2-1 セッションの推測

セッションIDの推測

  • PHPSSEIDのように推測しやすいやつ
  • 連番によるセッションID
  • 桁数の少ないセッションID
  • ユーザ情報を単純にハッシュしたセッションID

2-2 不適切な承認

不適切な承認

cookieの書き換えでログイン状態になるとか・・・

2-3 セッションの固定

セッションの中身までが固定で決まってる・・・・

2-4 クロスサイトリクエストフォージェリ

CSRF対策

csrf対策用のhiddenキーを仕込むのも一般的

2-5 補足:Cookieで「secure 属性」を指定 保険的な対策

2-6 セッションハイジャック

3-1 対応


# 対策系 # 全てsページの場合での注意は必要 Header always append X-Frame-Options SAMEORIGIN Header always set X-Content-Type-Options "nosniff" Header always set X-XSS-Protection "1; mode=block" Header set Strict-Transport-Security "max-age=315360000; includeSubDomains; preload"

3 クライアントがわでの攻撃

  • HTTP リクエストの作成などに / chrom extension REST Client
    https://qiita.com/KAZ0225/items/354b7726e650e9bda45d

上記でTRACEを送る方法で405で返ってくれば対策はされてると考えて良い。

3-1 クロスサイトスクリプティング

クロスサイトスクリプティング対策 ホンキのキホン

クロスサイトスクリプティング対策としてやるべき5つのこと

テンプレートエンジンを使う事により、対策となる物も

3-2 コンテンツの詐称

4 コマンドの実行

4-1 バッファオーバーフロー

4-2 書式文字列攻撃

4-3 LDAP インジェクション

4-4 OS コマンドインジェクション

http://senmon.cfc.ac.jp/studentreport/report2/OS.html

4-6 SSI インジェクション

http://securitychecklist.net/security/cyber-attack/SSL-injection.html

4-7 XPath インジェクション

ユーザの入力に基づき、XMLドキュメントに対してクエリーを発行するようなWebシステムで発生
http://www.soi.wide.ad.jp/class/20040011/slides/18/33.html

5 情報公開

5-1 ディレクトリインデクシング

ディレクトリリスティングの危険性と対策方法

ディレクトリリスティングの危険性と対策方法

5-2 ソース記載による情報漏えい

5-3 推測可能なリソース位置

http://www.soi.wide.ad.jp/class/20040011/slides/18/38.html

6-1 機能の悪用

6-2 パストラバーサルについて

ディレクトリ・トラバーサルと対策

6-3 リダイレクタ

オープンリダイレクタ脆弱性に気をつける

6-4 不適切なプロセスの検証

7 その他、概念的にまとめた物

7-1 ヌルバイト攻撃

7-2 メールヘッダ・インジェクション、メール第三者中継

7-3 HTTPヘッダインジェクション、HTTPレスポンス分割攻撃

7-4 スクリプトインサーション


E 補足,未整理

  • telnet

Windows telnet コマンドで入力文字を表示する方法

HTTP/TELNETを利用してHTTPレスポンスヘッダを確認する

※ ただしtelnetはhttpsなどに非対応

telnetはHTTPSを喋れないので、openssl s_clientを使えばいい

どんな場面でhtaccessを使うのか?

apcheのhttpd.confで、出来る物に関してはそちらで対応した方が良い。
運用上のリダイレクトや共用サーバーでconfファイルがいじれない場合などに利用する。

  • リダイレクト処理
  • アクセス制限
  • URLの統一

などに使用する


前提条件

httpd.confファイルにて,AllowOverrideが有効になっている必要がある

<Directory />
~中略~
AllowOverride None
~中略~
</Directory>

<Directory "対象となるディレクトリ 例) /var/home/www">
~中略~
AllowOverride All
~中略~
</Directory>


リダイレクト処理について

シンボリックリンクを許可し、RewriteEngineをOnにする

.htaccessのでRewriteEngineをOnにするにはOptions FollowSymLinksを設定しなければならないとApacheの公式サイトにあります。

Options +SymLinksIfOwnerMatch

リダイレクト処理について


アクセスの制限と許可

htaccessへの直接のアクセスを制限

直接ブラウザなどから.htaccessにアクセスできないように制限する。

<Files ~ "^\.ht">
deny from all
</Files>

BASIC認証

別途 .htpasswdファイルが必要

ベーシック認証の暗号化形式にも注意
Password Formats

AuthTYpe Basic
AuthName "Input your ID and Password"
AuthUserFile /home/current/.htpasswd
AuthGroupFile /dev/null
Require valid-user

  • AuthTYpe Basic

現行ダイジェスト認証に対応しているブラウザも多いため、そちらを利用するのも良い

AuthTYpe Digest
※ Digest認証だと、ユーザーIDとパスワードがハッシュ関数を用いて暗号化され解析されにくくなります。
  • AuthGroupFile /dev/null
    グループ指定が無いという意味、グループを使用する場合は
    .htgroupファイルが必要

    ※グループやRequire の記述で.htpasswdファイルは一つで
    各ディレクトリ毎に.htaccessを用意して権限を分けやすくするというメリットはある。

参照

IP制限

BASIC認証、もしくはIP制限

Satisfy Anyがポイント

Basic認証の記述 + Satisfy Any + IP制限、許可 の順番で記述する。

AuthType Basic
AuthName "Input your ID and Password"
AuthUserFile /home/current/.htpasswd
AuthGroupFile /dev/null
Require valid-user

Satisfy Any

order allow,deny
allow from 100.100.100.100

細かくはこちらを参照

その他、細かなファイルや拡張子単位での制限


URLの統一

httpsに統一する

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

wwwありなしの統一

※ 前提条件として www.はサブドメイン


番外 FTPのIPアクセス制限(.ftpaccess)

  • [FTP接続制御!IPアドレスによるアクセス制限設定をする方法](https://www.nkshopping.biz/index.php?
    FTP%E6%8E%A5%E7%B6%9A%E5%88%B6%E5%BE%A1%EF%BC%81IP%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E3%81%AB%E3%82%88%E3%82%8B%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E5%88%B6%E9%99%90%E8%A8%AD%E5%AE%9A%E3%82%92%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95)

学習サイト

学習サイトまとめ

1 日本語で学べるサイト

2 英語も出来るなら

3 エンジニア向け以外の内容も含む物

  • Udemy

    基本有料ですが、まとまった学習が可能です。

  • 動学

    ソフトウェア系統を動画で学習するなら

  • Schoo

    中には変わった授業内容も

4 子供向け

AWS VPC

Amazon VPC(Amazon Virtual Private Cloud)

AWSのバーチャルネットワークはSG(セキュリティグループ)と呼ばれる管理ツールで細かく接続を管理する事が可能です。

サーバーへのアクセス権限やポートのホワイト、ブラックリストにいたるまでにGUIで設定できる為、非常に柔軟性があり、またそのSGに関連するサービス(例えばEC2インスタンス等)を含める事が出来ます。