Blocking from a hook is not stopping code execution

[estringana]

Description

Blocking a request from Appsec should stop customer code execution. However, when this blocking happens within a tracer hook, it does not stop executing customer code execution.

Reviewer checklist

• Test coverage seems ok.
• Appropriate labels assigned.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72.93%. Comparing base (906cbc5) to head (7c8f668).

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #2836      +/-   ##
============================================
- Coverage     74.80%   72.93%   -1.87%     
  Complexity     2781     2781              
============================================
  Files           112      139      +27     
  Lines         11017    15166    +4149     
  Branches          0     1022    +1022     
============================================
+ Hits           8241    11062    +2821     
- Misses         2776     3552     +776     
- Partials          0      552     +552     

Flag	Coverage Δ
appsec-extension	67.99% <ø> (?)
tracer-php	74.80% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

see 27 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 906cbc5...7c8f668. Read the comment docs.

[bwoebi]

I see, the tracer sandboxing is sandboxing the bailout away :-)
I suppose some it would be ideal to signal the tracer "please bailout again after catching this" :-D

[pr-commenter]

Benchmarks [ tracer ]

Benchmark execution time: 2024-12-26 11:33:25

Comparing candidate commit e459810 in PR branch estringana/blocking-within-tracer-hook with baseline commit 4cc2897 in branch master.

Found 2 performance improvements and 1 performance regressions! Performance is the same for 175 metrics, 0 unstable metrics.

scenario:MessagePackSerializationBench/benchMessagePackSerialization

• 🟩 execution_time [-6.415µs; -4.045µs] or [-3.750%; -2.365%]

scenario:PDOBench/benchPDOBaseline-opcache

• 🟥 execution_time [+12.800µs; +16.942µs] or [+7.143%; +9.455%]

scenario:TraceFlushBench/benchFlushTrace

• 🟩 execution_time [-1000.000ns; -1000.000ns] or [-50.000%; -50.000%]

[cataphract]

I think it's fine although it's a mystery to me why sandbox.{h,c} are written the way they are.

[Anilm3]

My main concern with this approach is that if someone changes the error message in appsec, it would stop working. Can you make changes on the appsec side to:

• Make sure the error messages are validated at compile time?
• Add comments specifying that the error message must not be changed.

[bwoebi]

Looks good to me.