Add ddwaf_object_stringl and ddwaf_object_map_addl

[KowalskiThomas]

What is this PR?

Needed for DataDog/dd-trace-py#18128.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 0% with 11 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.82%. Comparing base (e71d0da) to head (8dd1609).

Files with missing lines	Patch %	Lines
src/interface.cpp	0.00%	11 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #493      +/-   ##
==========================================
+ Coverage   84.71%   84.82%   +0.11%     
==========================================
  Files         190      190              
  Lines        9670     9214     -456     
  Branches     4186     4144      -42     
==========================================
- Hits         8192     7816     -376     
+ Misses        577      520      -57     
+ Partials      901      878      -23     

Flag	Coverage Δ
waf_test	84.82% <0.00%> (+0.11%)	⬆️

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

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Anilm3]

These helpers are from libddwaf v1 and so is ddwaf_object_map_addl and have been deprecated, master is in v2.

[KowalskiThomas]

@Anilm3 the reason why I initially made this PR is that I got a security report saying some payloads might be ignored by the WAF due to strlen stopping at the first null byte, which might not be the actual end of the string as far as Python is concerned.

>>> s = "0\x00thomas"
>>> print(s)
0thomas
>>> print(len(s))
8

Do you think the library/consumer-side should handle those cases before calling into the WAF? What would be the recommended workaround?

[Anilm3]

@Anilm3 the reason why I initially made this PR is that I got a security report saying some payloads might be ignored by the WAF due to strlen stopping at the first null byte, which might not be the actual end of the string as far as Python is concerned.

>>> s = "0\x00thomas"
>>> print(s)
0thomas
>>> print(len(s))
8

Do you think the library/consumer-side should handle those cases before calling into the WAF? What would be the recommended workaround?

@KowalskiThomas that's not really the issue I was trying to raise, the object constructors let you follow either approach. The issue with this PR is that your python code is likely using libddwaf v1, while master is on v2, therefore those helpers are not necessary. In addition, the helpers already exist in libddwaf v1.

[KowalskiThomas]

Thanks for the comment and explanation -- I discussed with the Python folks and this isn't a problem for Python anyway, so I'll just close everything. Very sorry for the noise.