2023/07 CTOへの日報まとめ

日報




2023-07-04
OAuthに関して、ユーザーに許可を要求し、許可がおりたら、認可サーバーからアクセストークンを受け取り、APIへリクエストを投げるという大まかな仕組みは理解していましたが、アクセストークンを受け取る前に認可コードを受け取り、認可コードをアクセストークンに交換する仕組みや認可エンドポイント・認可決定エンドポイント・トークンエンドポイント・イントロスペクションエンドポイントなど各用語の理解はできていなかったため、今日理解することができ、良い時間となりました。

2023-07-05
リフレッシュトークンの有効期限は、下記のようにAPIによって様々なため、各APIの仕様をしっかり理解することが重要だと感じました。

・無期限に有効であり、ユーザーが明示的に取り消す、または特定の条件(1年間ログインしていない等)を満たした場合のみ無効になる
・明確に数ヶ月から数年という期限を設けている
・新しいアクセストークンを発行する際に、新しいリフレッシュトークンも同時に発行し、古いリフレッシュトークンを無効にする

2023-07-10
問い合わせ対応にて、アクセスログとエラーログをはじめて使いました(今まではクエリログしか使っていませんでした)。「アクセスログでユーザーのアクセスを追い、ステータスコード500などのエラーが出ている箇所を見つけ、時刻を特定する。その後、エラーログにて該当時刻で絞り、出ているエラーを特定する。」という方法はとても便利?だと思ったため、これからも活用していきたいです。武器が増えたような気がしています。

2023-07-12
valuesカラム
① 1
② 0,1,2
③ 1,2
④ 0,1

例として、上記のような形でデータが挿入される可能性のあるvaluesカラムがあった場合に、valuesカラムに1を含むレコードを漏れなく抽出したい場合には、下記のようなwhere句が有効であることを知りました。

->where_open()
->where(‘values’, 1)
->or_where(‘values’, ‘like’, “%,1,%”).
->or_where(‘values’, ‘regexp’, “^1,”)
->or_where(‘values’, ‘regexp’, “,1$”)
->where_close()

本来、上記のような形でカラムに挿入することは望ましくないことだと思いますが、SQLで正規表現を用いることで、このような形式でデータが挿入されているカラムに対しても対応可能であることは勉強になりました。

2023-07-14
fuelphpのArrクラスのsearchメソッドとPHPのstrstr関数の存在をはじめて知りました。

2023-07-18
トランザクションにおけるロックと分離レベルの知見が増えました。
・共有ロックと排他(占有)ロックについて
・分離レベル(Read Uncommitted、Read Committed、Repeatable Read、Serializable)について

2023-07-20
JSのencodeURI関数とencodeURIComponent関数の概要や使い方をはじめて知りました。

encodeURI関数は、URI全体をエンコードする。
エンコードする文字としては「英数字 – _ . ! ~ * ‘ ( ) # ; , / ? : @ & = + $」以外。

encodeURIComponent関数は、URIの一部(クエリパラメータやパスの一部)をエンコードする。
エンコードする文字としては「英数字 – _ . ! ~ * ‘ ( )」以外。

2023-07-21
PHPの設定オプションの一つであるmax_input_varsという存在をはじめて知りました。

・PHPが一度の通信で受け入れることができる変数(パラメータ)の数を制御するもの(パラメータを配列に格納して送った場合、配列内の要素数が換算される)
・これには、$_GET、$_POST、$_COOKIEの各スーパーグローバルを通じて送られる変数が含まれる。
・この設定は、攻撃者が大量のデータを送信してサーバーを圧迫する可能性(DoS攻撃等)を防ぐために用意されている
・パラメータ数が設定値を超えたとしても、プログラムは止まらない。超過分のパラメータは無視され処理が続行する。そのため、意図しない動作をする可能性があり、注意が必要
・上限を回避する方法としては、渡すパラメータ数を構造的に減らす方法が挙げられる。下記2つの方法があると考えました
 〇 配列をimplodeして文字列として渡し、受け取ってからexplodeで配列に戻す
 〇 jsonで渡し、受け取り後、json_decodeする

2023-07-24
ファイル名をそのままにファイルを保存する場合、メール受信サーバーの設定によっては、ファイル名に特殊文字が含まれている場合に特殊文字が「?」や「/」に変換されてしまう可能性がある。これにより、ファイル表示時やダウンロード時に、ファイル名の全てが認識されず(「?」や「/」以降はカットされてしまい)、ファイルの表示やダウンロードが行われないことがある(Uri::string()の挙動)ということをはじめて知りました。ファイルを保存する際は、ファイル名をハッシュ値などに変換することの重要性を感じました。

2023-07-25
本日は、jQueryのalwaysメソッドの使い方を知ることができました。Ajax通信の成功, 失敗に関わらず、通信が終了した際に必ず実行したい処理を記述するためのコールバック関数ということで、通信中に表示するローディングを閉じたい場合などに利用することができると思いました。

2023-07-26
JSのstartsWith関数, endsWith関数をはじめて知りました。拡張子のチェックを行うときは、endsWith関数を使うと便利だなと思いました。また個人的には「英字の大文字と小文字は一致していない判定となりfalseを返す」という点が厳密な判定で良いなと感じました。

2023-07-27
Rawメールデータについて知見を深めることができました。
・Rawという言葉は、メールのコンテキストでは通常、メールの原始的または加工されていない形式を指す。
・これは通常、SMTP(Simple Mail Transfer Protocol)プロトコルが用いる形式で、 全てのヘッダー(From、To、Subjectなど)・本文(テキストまたはHTML)・添付ファイルを含むテキスト形式のデータを指す。
・Rawメールデータは、エンコーディング・MIMEタイプ・改行文字(CRLF)、そしてヘッダーと本文を分離する空行を含む一連の規約に基づいて形成される。これらの規約は、メールを送受信するシステムが互いに通信できるようにするためのもの。
・Rawメールデータは通常、問題解決やメール認証のチェック(SPF、DKIM、DMARCの結果がヘッダーに含まれる)のために使用される

2023-07-28
メールのRawデータの各項目が、どのような情報を表しているか知ることができました。

・Return-Path:メールのバウンス(エラーメッセージ)を送信する先のメールアドレス
・X-Original-To:最初の受信者のメールアドレス。これは通常、メールの転送や配送後の処理に使用される
・Delivered-To:最終的にメールが配信された受信者のアドレス
・Received:メールが転送されるたびに追加される、メールがどのサーバーを経由して受信者に到達したかの記録
・DKIM-Filter:メールがDKIM(DomainKeys Identified Mail)フィルタリングを通過したことを示すフィールド。このフィルタリングはメールの改ざん防止に寄与する。
・Authentication-Results:メールが認証メカニズム(SPF、DKIM、DMARCなど)を通過した結果
・Received:メールのルーティングの一部。これらのヘッダを下から上へと追っていくことで、メールが元の送信者から最終的な受信者に到達するまでの経路を追跡することができる
・DKIM-Signature:メールがDKIMにより署名されていることを示す。メールが特定のドメインから発信され、途中で改ざんされていないことを証明する。
・X-Google-DKIM-Signature:Googleが提供する追加のDKIM署名
・X-Gm-Message-State:Google Mailが提供するメッセージ状態情報
・X-Google-Smtp-Source:メールがGoogleのSMTPサーバーを経由して送信されたことを示す。
・X-Received:メールが受信された日時やサーバーの情報を示す。
・MIME-Version:メールがどのバージョンのMIME(Multipurpose Internet Mail Extensions)規格を使用しているか
・Date:メールが送信された日時
・Fromメールの送信者
・Subject:メールの件名
・Thread-Topic:メールが属するスレッドや会話のトピック
・Message-ID:メールに一意に割り当てられるID。メールの追跡や参照に使用される。
・Content-Transfer-Encoding:メール本文のエンコーディング方式
・Content-Type:メールのコンテンツのタイプ

また、X-で始まるヘッダフィールドはカスタムヘッダといい、メールシステムやアプリケーションによって特定の目的で使用される。

2023-07-31
CookieのHttpOnly属性について、理解することができました。

・HttpOnly属性は、WebアプリケーションがCookieに設定できるフラグの一つ。
・この属性が設定されているCookieは、JavaScriptなどのクライアントサイドのスクリプトからはアクセスできなくなる。
・これにより、XSS攻撃からCookieを保護することができる。(XSS攻撃によりCookieが盗まれることで、セッションハイジャックに繋がる)
・ただ、HttpOnly属性はXSS攻撃を完全に防ぐものではなく、あくまでその一部を緩和するものである。