Cross Site Scripting (XSS) relies on two things; the MVC View decoding data in raw HTML format and users being able to input the data to be decoded (and a lack of verification of it).

In .Net development @Html.Raw is the command that must be set to enable raw data to be interpreted as HTML in the View. The advantages and use's of @Html.Raw are as such, Users (or the Website Developer) can enter data and also HTML commands such as 'strong' tags to bolden and emphasize a word or sentance or the newline character 'br' to create a new paragraph, or commands for italics, different colors, borders and such and such in a string of text. This 'string' of data is then held in the database ready to be decompiled into a section of a webpage.

The aformentioned method of creating webpages is advantageous to the Developer and difficult to allow input from the User without. It allows the data to be passed as a large string from the Model, a database, a text file or even scrapped from a url and minimal code to be set in the View to universally format it. As breifly mentioned before this can be done with or without using @Html.Raw functionality to allow HTML formatting tags such as 'strong' which can be convienient or most notably 'br' tags to set a newline, a paragraph or even dot points (including the dots, but this could be accomplished without @Html.Raw, notably passing each paragraph in a foreach and/or predifining HTML structures). This functionality can be abused however, notably using the 'script' tag although its unlikely a Developer would introduce a virus into his own code and said functionality is no different to that of creating a website. Although, this can be a different story if a user provides the data. For example a message board where a user is asked to leave a message, the user leaves a message and its stored in the database, then a request to view message board is recieved and as raw HTML formatting is active the message the user left will be processed as HTML and if a malicious 'script' was included with that messsage then the message board website will now be executing that script whenever the message is viewed and is infected with a XSS Worm.

This can also happen through user defined data send through Javascript without proper escaping using a function like @HttpUtility.JavascriptStringEncode() where extra Javascript code can be sent to a Javascript function expecting a variable.

SQL Injection is where SQL Commands are passed with user input variables such as Usernames.

For instance, I have a website that asks for a username which is to be queried against the records in the database, it expects someone@somewhere.com and it will prepare that value something along the lines of 'SELECT * FROM Usernames WHERE Usernames.Username = someone@somewhere.com' and send that to the database. Thats all well and good and it may serve its function though a simple implementation like that opens up a very distinct (or not) vulnerability which is one could enter their username as '; SELECT Password, Username FROM Usernames' which will resolve as 'SELECT * FROM Usernames WHERE Usernames.Username = ; SELECT Password, Username FROM Usernames' which will return all passwords and usernames (joined together) from the Username table which would defeat the purpose of having a Username table in the first place. Despite that, commands even more malicious than that can be sent, infact with an implementation such as that its total free reign.

The best defence against SQL Injection from the lowest level (Irrespective of frameworks such as ADO and Entity) is to pass variables as parameters to Stored Procedures in the SQL database and within those Stored Procedures to never concatenate as this 'resets' the variable type of the item (known as a Dynamic Procedure ?) and for a READ to have the Proceduce access a View. Inclusive of this is to also create a User in the database to be used by the program with only READ & UPDATE priveledges and further to that, encrypt their connection string (in web.config using CMD) and if one is still keen there are some tricks that can be pulled off with Triggers.

A very complicated phenomenon indeed. The first prerequisite is to have present in your browser cache a valid authentication token for something like a internet banking site you visit. Now the second part is visit a let's say 'hostile' website (or a bad email, and can even include a <img> src attrib) which includes a script designed to visit that internet banking site.

Its not all doom and gloom though as setting the cookie attribute 'samesite' to 'strict' which is generally common practice especially for a sensitive cookie will generally prevent this outright, and thats its function really. Alternatively you can use 'samesite=lax' and that will mostly prevent XSRF but thats beyond the scope of this article.

Though that said all financial institutions that are half reputable use a additional protection layer, a 'XSRF protection token'. I imagine its a session cookie (deleted upon page leave) after the bank forces a clean refresh of their site but not having the need to make one (so far) I dont really know, but if you are a bank, well atleast you know where to start :)

Buffer Overflow is probably the most infamous expolit of them all, it was one of the first and easily predates the internet.

A typical example of Buffer Overflow relys on a field that expects user data and has allocated an amount of RAM for it and does not check the length of the input compared to whats been allocated.

What can happen from here is that instead of a user entering say a username, they enter carefully constructed code and code that exceedes the length of the allocated buffer. Firstly anything that was present in RAM after the allocated buffer has been overwritten therefore important variables and alike that the website/program requires are now missing and at best this will cause a crash, which could be described as a DoS (Denial of Service). Although, and probably more commonly the system wont crash but instead run its natural course and when it tries to reference something in memory that was overwritten it will find code crafted by the attacker and thats when the system has been compromised.

Most web applications install packages to enhance functionality of the site, ie Bootstrap.

While the developer can follow best practises and create a site that is secure, somewhat frequently some packages it relys on are not. Assuming the package developer has released a fix for the package (which is generally the case) the package has become outdated an needs to be replaced with the updated version.

In the .Net world the NuGet Package Manager is where this action can be performed and likewise in Node it can be done in NPM or one of its variants.

The solution from here is to simply select the package and update it although this comes with a fairly major caveot in that a lot of packages come with 'breaking changes'. This means that sometimes when a package is updated they change the function names or alike and your application in its current form is not longer compatible with the package. This doesnt happen that often depending on the package but it can be more common than one may think.

This leaves two courses of action, to upgrade to the absolutely latest version and if it breaks the application then to upgrade the application to be compatible again, or if it breaks the application to instead update to the latest hotfix version, something along the lines of 2.2.2 >> 2.2.4 or 2.2.2 >> 2.3.2 instead of 2.2.2 >> 3.1.1.

This is why a lot of people still use old (but hotfixed) versions of Bootstrap as they revamped the CSS commands and nobody wants to revamp the entire application to be compatible, also later versions of Boostrap are much bigger files.So you may be asking, how do I know what to update to a Major version (x.0.0), a minor version (0,x,0) or a hotfix (0,0,x)? There are a few ways to approach it. One is to simply backup the application somehow, update it to full and test to see if anythings broken. Or, Take note of all the package versions, update and revert if something breaks. Or, research all the packages to see which will break and decide from there. After briefly consulting ChatGPT it would seem that option 1 is reasonably common atleast in the freelance community, but either way remember to note the problematic package and source-control/backups are important!

An old one but a good one. Password Hashing refers to storing users Passwords in the database as a Hash, as opposed to clear text. This prevents Passwords from being disclosed due to a Database breach.

The advantage of a hash is that a hash can be calculated from a value easily, alhough calculating the value from a hash is much more difficult. The difficulty of this can be further increased by creating a hash from the value (the Password) and from a Salt, a random number created per value to decrease the ability to compare password hashes to each other and to add other forms of obfuscation.