|
| 1 | +### Overview |
| 2 | + |
| 3 | +To improve security and logistics we need to allow limiting Actions to processing only requests with certain HTTP methods and add those limitations to as many existing Actions as possible. |
| 4 | +There are many vulnerabilities caused by actions processing both GET and POST requests and thus allowing bypassing security validations like form key validation. Also limiting actions to processing only requests with certain methods would serve as self-documentation for Action classes and improve consistency of server side for client code and functional tests. |
| 5 | + |
| 6 | +### Theory of Operation |
| 7 | + |
| 8 | +Since we use by-convention routing it would be inconsistent to defined actions’ allowed HTTP methods in a config file, so it’s better to create marker interfaces like these: |
| 9 | + |
| 10 | +>interface HttpGetActionInterface extends ActionInterface |
| 11 | +> |
| 12 | +>{ |
| 13 | +> |
| 14 | +>} |
| 15 | +> |
| 16 | +> |
| 17 | +>interface HttpPostActionInterface extends ActionInterface |
| 18 | +> |
| 19 | +>{ |
| 20 | +> |
| 21 | +>} |
| 22 | +> |
| 23 | +> |
| 24 | +>interface HttpPutActionInterface extends ActionInterface |
| 25 | +> |
| 26 | +>{ |
| 27 | +> |
| 28 | +>} |
| 29 | +
|
| 30 | +etc. |
| 31 | + |
| 32 | +One interface per each HTTP method (using list of HTTP methods from \Zend\Http\Request::METHOD_* constants). We will have an exentable map *HTTP method* => *Interface* passed to the validator to allow custom HTTP methods to be processed. |
| 33 | + |
| 34 | +Request method will be validated in the FrontController before executing a matched action, somewhat like this: |
| 35 | + |
| 36 | +>if (!(array_key_exists($request->getMethod(), $interfaceMap) && $actionInstance instanceof $interfaceMap[$request->getMethod()])) { |
| 37 | +> |
| 38 | +> throw new NotFoundException(__(‘Page not found.’)); |
| 39 | +> |
| 40 | +>} |
| 41 | +
|
| 42 | + |
| 43 | +To limit already existing Actions and get developers to know these new interfaces a temporary event listener will be added for controller_action_postdispatch event to log HTTP methods used with actions and then the full suite of functional tests (MTF and MFTF) would be ran to get information on as much actions as possible. |
| 44 | + |
| 45 | +After corresponding Http*Method*ActionInterface will be added to every Action class we have information on. If an action is logged to be accessed only by GET methods it will allow only GET, if only by POST – allowing only POST etc. If by more than one methods – the Action will be investigated and either updated to implement multiple interfaces or left alone if proven too difficult to determine HTTP methods. |
| 46 | + |
| 47 | +To sway developers to specify HTTP methods for actions a new rule for code mess detector will be added that will require implementations of ActionInterface to implement also at least one of Http*Method*ActionInterface interfaces. |
| 48 | + |
| 49 | +### Work Breakdown |
| 50 | + * Add Http*Method*ActionInterface and implement request validation in the FrontController |
| 51 | + * Add a rule to code mess detector |
| 52 | + * Create logging mechanism for Actions |
| 53 | + * Log HTTP methods used when running full functional tests’ suite |
| 54 | + * Create script to add Http*Method*ActionInterface to Action classes we’ve collection information about |
| 55 | + * Update Action Classes |
0 commit comments