I came across this very interesting article explaining correct use of PATCH in HTTP world. Worth reading even if little out-dated!
https://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/
Skill to do come from doing…
I came across this very interesting article explaining correct use of PATCH in HTTP world. Worth reading even if little out-dated!
https://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/
Although this information may seem innocuous, it allows an attacker to identify the version of server side components and therefore target further attacks to this specific software. This can quickly lead to successful exploitation if the server side components have vulnerabilities with publicly available exploit code. The server software versions used by the application are revealed by the web server. Displaying version information of software information could allow an attacker to determine which vulnerabilities are present in the software, particularly if an outdated software version is in use with published vulnerabilities.
See the following guide for removing the headers from IIS and ASP.NET: https://blogs.msdn.microsoft.com/varunm/2013/04/23/removeunwanted-http-response-headers
It is recommended that functionality is implemented within the application that detects when an error has occurred and redirects the user to a custom error page that does not disclose any form of sensitive data. These errors that should induce a redirect to a custom error page should include 403 Forbidden Errors – to prevent an adversary from enumerating existing pages on the application that require prior authentication to view; 404 Not Found pages; and 500 Internal Error pages. Alternatively, simply redirecting a user to the applications home page can also suffice in reducing the level of information disclosed.
For ASP.NET, in web.config set one of the following options:
<customErrors mode="RemoteOnly" /> <customErrors mode="On" />
A number of HTTP Security Headers have been introduced in recent years to enhance security of a website by providing protections against certain types of attacks. The following table contains the headers which fall under this vulnerability category, notes are offered in the technical analysis as to which headers are missing and any misconfiguration discovered during the engagement.
It’s strongly recommended that these headers are configured on all applications to further harden the application from attack.
Few example headers that should be used:
Additional information, plus examples of all headers to consider can be found at https://securityheaders.com
Cross-Site Request Forgery (CSRF) vulnerabilities arise when applications rely solely on HTTP cookies to identify the user that has issued a particular request. Because browsers automatically add cookies to requests regardless of their origin, it may be possible for an attacker to create a malicious web site that forges a cross-domain request to the vulnerable application. For a request to be vulnerable to CSRF, the following conditions must hold:
The most effective way to protect against CSRF vulnerabilities is to include within relevant requests an additional token that is not transmitted in a cookie: for example, a parameter in a hidden form field. This additional token should be random enough such that it is not feasible for an attacker to determine or predict the value of any token that was issued to another user. The token should be associated with the user’s session, and the application should validate that the correct token is received before performing any action resulting from the request.
An alternative approach, which may be easier to implement, is to validate that Host and Referer headers in relevant requests are both present and contain the same valid domain name. The Origin header can also be validated against the Host, however some browsers do not support this for requests made from the same domain, therefore this mechanism would need to use the Referer header as a fallback. For AJAX requests, a custom header can be added and then checked server-side (e.g. “X-Requested-With: XMLHttpRequest”), because this cannot be passed cross-domain without CORS being enabled.
However, these header checking approaches are somewhat less robust. Historically, quirks in browsers and implementation errors have often enabled attackers to forge cross-domain requests that manipulate these headers to bypass such defence.
This is excerpt from ASP.NET Core documentation on semantic versioning. Full document can be found here
The .NET Core Runtime roughly adheres to Semantic Versioning (SemVer), adopting the use of MAJOR.MINOR.PATCH
versioning, using the various parts of the version number to describe the degree and type of change.Copy
MAJOR.MINOR.PATCH[-PRERELEASE-BUILDNUMBER]
The optional PRERELEASE
and BUILDNUMBER
parts are never part of supported releases and only exist on nightly builds, local builds from source targets, and unsupported preview releases.
MAJOR
is incremented when:
MAJOR
version of an existing dependency is adopted.MINOR
is incremented when:
MINOR
version of an existing dependency is adopted.PATCH
is incremented when:
PATCH
version of an existing dependency is adopted.When there are multiple changes, the highest element affected by individual changes is incremented, and the following ones are reset to zero. For example, when MAJOR
is incremented, MINOR
and PATCH
are reset to zero. When MINOR
is incremented, PATCH
is reset to zero while MAJOR
is left untouched.