Confirmed users
971
edits
Find My Device Security Review: Difference between revisions
Find My Device Security Review (view source)
Revision as of 17:56, 15 September 2014
, 15 September 2014no edit summary
No edit summary |
No edit summary |
||
| Line 28: | Line 28: | ||
===== No Content Security Policy is used ===== | ===== No Content Security Policy is used ===== | ||
Risk: medium | '''Risk: medium''' | ||
Ideally applications, specially new applications, have a strict content security policy. This is not a complicated application and applying a content security policy should be simple. The only page where inline (CSS) code is present is the 404.html, which should be easy to move to a separate CSS file. | Ideally applications, specially new applications, have a strict content security policy. This is not a complicated application and applying a content security policy should be simple. The only page where inline (CSS) code is present is the 404.html, which should be easy to move to a separate CSS file. | ||
| Line 36: | Line 36: | ||
===== Robots.txt present but not used ===== | ===== Robots.txt present but not used ===== | ||
Risk: low | '''Risk: low''' | ||
The project contains a robots.txt file in the content directory (static/app) but it is not actually services. Requests for /robots.txt serve the index.html instead. Not sure if this is intentional or a server misconfiguration. | The project contains a robots.txt file in the content directory (static/app) but it is not actually services. Requests for /robots.txt serve the index.html instead. Not sure if this is intentional or a server misconfiguration. | ||
| Line 42: | Line 42: | ||
===== Unused .htaccess file ===== | ===== Unused .htaccess file ===== | ||
Risk: low | '''Risk: low''' | ||
The content directory contains a .htaccess file. It is not clear if this project is ultimately being served with Apache, but considering most deployments happen with NGINX this is unlikely. | The content directory contains a .htaccess file. It is not clear if this project is ultimately being served with Apache, but considering most deployments happen with NGINX this is unlikely. | ||
| Line 50: | Line 50: | ||
===== No replay protection for Hawk-signed requests ===== | ===== No replay protection for Hawk-signed requests ===== | ||
Risk: medium | '''Risk: medium''' | ||
From the github.com/hueniverse/hawk project: “Without replay protection, an attacker can use a compromised (but otherwise valid and authenticated) request more than once, gaining access to a protected resource. To mitigate this, clients include both a nonce and a timestamp when making requests. This gives the server enough information to prevent replay attacks.” | From the github.com/hueniverse/hawk project: “Without replay protection, an attacker can use a compromised (but otherwise valid and authenticated) request more than once, gaining access to a protected resource. To mitigate this, clients include both a nonce and a timestamp when making requests. This gives the server enough information to prevent replay attacks.” | ||
| Line 58: | Line 58: | ||
===== Hawk Unit Tests are not complete enough ===== | ===== Hawk Unit Tests are not complete enough ===== | ||
Risk: medium | '''Risk: medium''' | ||
It would be nice to see more unit tests for the Hawk module. For example what is missing now is a test to validate that a Hawk signature over a POST request is also correctly handled. And specifically, if a malicious/invalid/modified POST request correctly fails to pass the Hawk authentication checks. | It would be nice to see more unit tests for the Hawk module. For example what is missing now is a test to validate that a Hawk signature over a POST request is also correctly handled. And specifically, if a malicious/invalid/modified POST request correctly fails to pass the Hawk authentication checks. | ||