DESIGNING EDITING FUNCTIONALITY PART TWO

DESIGNING EDITING FUNCTIONALITY

INSTALL A WYSIWYG EDITOR

At the moment for the description we used a very normal Text Area. This may not work well because if the lecturer wanted to explain the contents of his course in full, he would not have the opportunity to do so. We will replace the header box with an editor, so being able to use subtitles, put bold characters etc. We will see that a WYSIWYG editor can also pose security risks. The Text Area will remain within the form; an editor is not meant to replace it, rather to supplement it.

The user through the editor formats the content in HTML, when he is finished the content will be poured into the Text Area.
The editor we will use is Summernote, it integrates with Bootstrap. Let’s go to the following address https://summernote.org/getting-started/ – for-bootstrap-5 The files we download should not be put in the Layout View because all views can access these files, rather we will put them exclusively where the editor is used. Let’s create a new partial view _Summernote. This is the code.

HTML ENTITIES

As we save the edited and formatted description content to HTML, the content itself is poured into the Course Detail Text Area. However, the Razor engine renders that HTML code harmless by printing special characters called HTML Entities. Let’s see with a slide how it works and how to solve the problem.

PREVENT CROSS-SITE SCRIPTING (XSS) ATTACKS

Even if we limit the number of editor buttons malicious users can still modify the HTML code produced. One can, for example, insert a script tag with arbitrary JavaScript code. Opening the Browser tools, going to the Elements tab looking for the Text Area we can insert for example an alert, the lesser of evils, annoying but not harmful.

If I can put in some Javascript, when the user has logged in you can steal that user’s personal information, first name, last name and why not the credit card. That is why when we make purchases the card number is never shown in its entirety, but for example only the last four digits. It can add Ads, i.e., advertisements and profit from them. Also, with XSS, malware can be injected by exploiting known vulnerabilities of various Browsers.

We see that the malicious code, although in this case it is a simple alert is stored in the database and displayed to users on the detail page.

Let us now look at a couple of places where we can intervene. The first is before the data ends up in the database, doing sanitization, that is, cleaning up the content from the script tags, or we do validation, we send the form back to the user and inform them.

For completeness we will operate the sanitization at another point, although it is more risky because if we have to display the database content on another View we have to remember to do the sanitization. We let the JavaScript code end up in the database and only when we display that description do we sanitize the input.

PROTECT YOURSELF FROM CROSS SITE SCRIPTING (XSS) ATTACKS

In our case to protect the application we used a component HtmlSanitizer and created a helper tag HtmlSanitizeTagHelper.cs which I reused in the edit and detail views of the course. This is the code.

UPLOAD A FILE FROM THE FORM

In some situations we need the user to upload one or more files by choosing them from their Hard Disk. In our case it will be the course image, again we will do validation because the user could upload an executable, zipper file etc. In the Edit form we need to use the attribute enctype=”multipart/form-data” which is necessary when we need to load a binary file.