forked from owasp-modsecurity/ModSecurity
-
Notifications
You must be signed in to change notification settings - Fork 5
/
Copy pathTODO
126 lines (69 loc) · 4.13 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
To remove:
- SecStatusEngine
- SecCacheTransformations
- SecChrootDir, SecServerSignature
- SecConnEngine, SecConnReadStateLimit, SecConnWriteStateLimit, SecReadStateLimit, SecWriteStateLimit
- SecGsbLookupDb and @gsbLookup
- SecHashEngine, SecHashKey, SecHashMethodPm, SecHashMethodRx, SecHashParam; @validateHash; ctl:hashEnforcement; ctl:hashEngine
- SecRemoteRules, SecRemoteRulesFailAction
- SecStreamInBodyInspection, SecStreamOutBodyInspection; @rsub; STREAM_INPUT_BODY, STREAM_OUTPUT_BODY
- SecHttpBlKey and @rbl
- pause
- skip
- SecGuardianLog
Areas of interest:
- If proxy doesn't work in phases 3+, say so when starting up. Not at runtime.
- If ctl is used to modify a rule that runs first, say so when starting up.
- SecInterceptOnError makes no sense as currently implemented.
- SecInterceptOnError: no need for a special-purpose directive, mechanism
for all similar situations? Review all similar situations.
- SecTmpSaveUploadedFiles???
- Actions deprecatevar and expirevar are inconsistently implemented; generally,
persistent storage is too low level and difficult to use
- Some of the multipart flags don't make sense or produce FPs
- TX:MSC_.*
- Part J is a mess.
- Nginx and IIS ports; are they worth keeping?
- JSON parsing implementation not consistent with how XML is done. For better or worse?
- JSON audit logging; maybe keep, but make compatible with mlogc?
Small improvements:
- Phase 1 and 2 rules run at the same entry point in Apache. In other words, apply
--disable-request-early permanently.
- Why does the GLOBAL collection need to be initialised?
- We need a way to specify permanent collections, from which records are not deleted.
- ModSecurity should be able to fully control output (response body) when
intercepting transactions (not force users to rely on ErrorDocument, which can be problematic).
- Heavily normalised REQUEST_URI variable that can be used without thinking
about evasion (much).
- Need variable CONTENT_TYPE; ModSecurity should parse and normalize the C-T header,
ignore the semicolon if any, and produce a value that can be safely used in rules.
- In proxy mode, knowing what type of system is in the backend could be useful; for
example, if it's IIS, you know it's case-sensitive, etc. So having some sort
of backend behaviour modelling could be interesting. Also, ModSecurity should
parse and re-create the request URI before passing it onto the proxy. That
would ensure that it understood whatever it sent to the backend.
- Automating request processor activation as default; option to switch to manual
- SecDefaultAction only allowed to specify blocking actions; rules must specify phase
- Change directive name?
- Not clear if IDs should remain mandatory; maybe only for rule sets
- In fact, allow only a subset of directives/features in rule sets
- Sane limits for SecPcreMatchLimit and SecPcreMatchLimitRecursion
- All rules that have the same targets and tfns reuse work (caching)
- Lua modules (scripts that handle multiple phases); remove SecRuleScript?
- Stay with Lua 5.1 for the JIT?
- @lua (or @script) operator
- Is PCRE JIT used by default?
- Location matching is prone to evasion; maybe add a special variable to use?
- setvar:IP=1 silently fails
- Don't allow rules to manipulate collection variables prefixed with __
- Check: allow:phase allowed only on phase 1 and 2 rules.
- It's not possible to reinitialise a collection. This is necessary for session collections to
handle cases when the session ID is rotated. Maybe keep all session data, just change the ID?
- Tracking sessions is currently fidly. ModSecurity should be able to do it directly after being
told what's the name of the cookie that carries IDs.
Bugs:
- https://github.com/SpiderLabs/ModSecurity/pull/1224
- Incorrect log message "Ctl: Set requestBodyAccess to %d." when ctl:forceRequestBodyVariable is used.
- ctl:forceRequestBodyVariable is weird. If you set XML parsing and it goes without error, you don't
get REQUEST_BODY. If there's an XML parsing error, you do. Request body buffering shouldn't be
coupled with body processing.