Hi ye all,
[i]Always trying to enhance the overall security of the website security landscape.
We do not see results in security improvements (thanks, Eddy etc.), but we won’t give up.
When there is just one single website owner or admin that improves the security of the website code in question,
we will see what we like to see, and that is just why we keep doing, what we are doing here.[/i]
Damian
Where we found a C-status: https://sritest.io/#report/81eebd54-ecaf-4261-afcd-408251a0d5fd
With error in the script here:
function _classCallCheck(t,e){if(!(t instanceof e))throw new TypeError("Cannot call a class as ain link: Results from scanning URL: htxps://cdnjs.cloudflare.com/ajax/libs/foundation/6.3.1/js/foundation.min.js
Number of sources found: 130
Number of sinks found: 3
Better results here: http://retire.insecurity.today/#!/scan/b7b79eb501f7c458d22d752561aa94e45e4b0960924b87d1a746b776d884954f
A meagre F-status here: https://observatory.mozilla.org/analyze.html?host=tripshare.azurewebsites.net
supported by these Asafaweb scan results: Overview
Cookies served over HTTPS but not flagged as “secure” may be sent over an insecure connection by the browser. Often this may be a simple request for an asset such as a bitmap file but if it’s on the same domain as the cookie is valid for then it will be sent in an insecure fashion. This poses a risk of interception via a man in the middle attack.
Result
It looks like a cookie is being served over HTTPS without the “secure” flag being set (name : value):
ARRAffinity : 5adf72a26XXXXXXXXXXXe02dac720ca7f741aafa880fdc7ab8f5cca6295b47fc3
Unless the cookie needs to be sent over an insecure connection, the “secure” flag should always be set to ensure it can only be sent with an HTTPS request.
HTTP Only cookies: Overview
Cookies not flagged as “HttpOnly” may be read by client side script and are at risk of being interpreted by a cross site scripting (XSS) attack. Whilst there are times where a cookie set by the server may be legitimately read by client script, most times the “HttpOnly” flag is missing it is due to oversight rather than by design.
Result
It looks like a cookie is being set without the “HttpOnly” flag being set (name : value):
ARRAffinity : 5adf72a267ccd22ebede02dac720ca7f741aafa880fdc7ab8f5cca6295b47fc3
Unless the cookie legitimately needs to be read by JavaScript on the client, the “HttpOnly” flag should always be set to ensure it cannot be read by the client and used in an XSS attack.
Missed here: https://webcookies.org/cookies/tripshare.azurewebsites.net/4810635
Hi, Microsoft & CloudFlare, N.B.: scoring 7 red out of 10 risk status here: http://toolbar.netcraft.com/site_report?url=https%3A%2F%2Ftripshare.azurewebsites.net → https://aw-snap.info/file-viewer/?protocol=not-secure&tgt=tripshare.azurewebsites.net&ref_sel=GSP2&ua_sel=ff&fs=1
polonus (volunteer website security analyst and website error-hunter)