Laraveler のみなさん、アプリのセキュリティ、気にしてますか？
何となく「Laravel がよしなにやってくれてる」で片付けてませんか？
安心してください、私もです。
XSS、CSRF、SQLインジェクション、セッションハイジャック、ファイルアップロード脆弱性、ログイン機構に対する攻撃、etc。
今回は、これらそれぞれの攻撃に対して、Laravel が何をしてくれているのか、その実装を追っていきたいと思います。
思わぬ落とし穴も見つかるかもしれません。

サービスが成長すると愚直にコードを書いているだけではパフォーマンスの問題にぶつかります。
参照はcacheやリードレプリカを増やすことで対応することができますが、書き込みが多い場合はそういうわけには行きません。

PHPの鬼門ともいえる、書き込み処理を如何に改善していくか。
そのために必要な基本的な考え方や実際のアプローチについて説明します。

話をすること

• イベントアーキテクチャとイベントストリーミング
• 書き込みをスケールさせるために必要な勘所
• 運用するときに陥る落とし罠
• 現場で必要な考え方

コロナ禍以来、リモートワークの普及が進み、社内システムやプロダクションサーバへの安全なアクセスとその監査の重要性が増しています。私はこの新たな働き方を支えるため、SSHの多要素認証、短命な証明書による公開鍵認証、そしてWazuhやFalcoを活用した監査基盤の構築に取り組んできました。

特にPHP開発者にとって、セキュリティはしばしば遠い存在と感じられがちです。しかし、実は私たちの日常的な開発プロセスに深く関わるものであり、特にリモートワークが常態化する今、セキュリティ意識は必須のスキルとなっています。このセッションでは、ゼロトラストネットワークの基本概念を踏まえつつ、PHP開発者が容易に取り組めるセキュリティ対策を実践的な視点から解説します。開発プロセスにおけるセキュリティの組み込み方、安全なリモートアクセスの確保方法、そしてアクセス監査の自動化について、具体的な事例と共に紹介します。

検索機能は現代の情報検索の基礎で, 多くのWebサービスに搭載されています.
検索機能の実装者としてElasticsearchなどの全文検索エンジンを使ったことのある方も多いと思われます.

一方で, その内部実装を知っている方は多くないのではないでしょうか？
本セッションは検索エンジンをフルスクラッチ実装しながら解説するパワフルなコンテンツです！

基本的な検索エンジンの実装のトピックとして、以下を想定しています

• 転置INDEXの実装
• AND / OR検索の実装
• 簡単な結果ソート手法(スコアリング)の概要と実装
• ElasticSearchなど実用的な全文検索システムにおけるスコアリングの概要実装

このセッションの対象者:

• 検索の仕組みに興味がある方
• 全文検索エンジンを使ったことがあるが内部の仕組みはよくわからないという方

PHPはWebアプリケーション開発に特化したプログラミング言語です。Webアプリケーション開発においては非常に柔軟で強力ですが、リレーショナルデータベース(RDBMS)を作ることには全く向いていません。

全く向いてないにも関わらず、なぜPHPでRDBMSを作るのか？大きく分けて２つの理由があります。一つは車輪の再開発によりRDBMSの仕組みを深く理解できること、そしてもう一つはロマンです。例えば、WordpressがピュアにPHPだけで動作したら、なんだかワクワクしますよね！

本トークで話す内容

• PHPで動くデータベースのデモ
• RDBMSを作るために必要な構造・設計の基礎知識
• PHPだから理解できるデータベースのコア実装
• ステップ実行でクエリが処理される様子を観察

皆さん、php-src （PHP 処理系のコード）読んでますか？

PHP 処理系は C 言語で書かれたプログラムであり、多くの大規模 C プロジェクトと同様にプロジェクト固有のマクロが広く使われています。言語処理系のコードというもの自体が読むのに前提知識を要するのもあり、学校で少し C を習ったことがあるくらいの人だと、読みこなすのはけっこう骨が折れます。

しかし PHP で仕事をしていく中、処理系実装を追えると簡単に解ける疑問、原因究明が楽になるトラブルシュートは案外多いです。全員といわずとも、10 人くらいのチームごと 1 人でも読める人がいれば助かる日は多いことでしょう。

このトークでは PHP スクリプトに書かれた文字列リテラル 'hello world' が処理系に読み込まれコンパイル・実行され出力バッファや SAPI 層を通りぼくらの画面へ届くまで、を駆け足で解説します。

システム運用/開発において、取り扱いが難しいもののうちのひとつとして、「過去」や「未来」があると思います。

たとえば、「履歴データ」と呼ばれるようなものの取り扱い、あるいは「予約された時間になんらかの処理をしたい」という要件に対しては、「システムを作ったはいいけど運用していく中で取り扱いに困ってしまった」という経験はないでしょうか？

「現在の状態」だけを相手にすればいい場合は非常にシンプルで済むシステムも、過去や未来を取り扱おうと思った途端に複雑性が上がるというのは、私の実感とも一致します。

本セッションでは、「過去」「未来」を取り扱うにあたって、「そもそも何が難しいのか」と、その難しさに対する処方箋、およびそこから見えてくる勘所と考え方を考えてみたいと思います。

過去のPHP(特に５系まで)では、型システムが未熟であり、型の変換や関数の引数や返り値の型が厳密に管理されなかったため、関数を利用する際に適切な型の値を渡すことが難しかったり、返り値の型を信頼できない場合がありました。現在名前ベースで一致を調べる型システム(nominal type system) を採用していますが、他の言語と比べて、どうなのかを次の観点をベースにお伝えします。

1. 採用している型システムの考え方のメリットデメリット(nominal type systemなど)
2. 型コンパイルのタイミングが異なることによる影響
3. 1,2では難しいポイントを各言語ではどう問題解決しているのか？
4. 型システムの違いが及ぼす業務コードを書くことへの影響