Users are able to create content in Moodle by either using the resource editor or uploading files. A number of settings are available to partly prevent the misuse of these.

HTML allows the embedding of code that uses the explicit <EMBED> and <OBJECT> tags. This mechanism has recently gained popularity with sites, such as YouTube, Prezi, Voki, and Google Maps, providing code to be embedded for their users. Potentially, malicious code can be put in the embedded script, which is why its support is deactivated by default. To activate it, go to Security | Site policies and locate the Allow EMBED and OBJECT tags parameter:

Moodle's editors automatically remove any unwanted HTML elements and attributes via a so-called HTML purifier. Moodle supports a more secure version called HTML Purifier. You have the ability to bypass this mechanism for individual users. Firstly, you have to set the Enable trusted content parameter, as shown in the preceding screenshot. Secondly, you will have to allow the moodle/site:trustcontent capability for each user who you trust to submit JavaScript and other potentially malicious code.

The multimedia plugin supports a number of audio and video formats. Shockwave Flash (SWF) files can contain code that could cause problems on users' local machines. SWF files will only be embedded if the Flash animation parameter, which you can see by going to Appearance | Media embedding, is turned on and trusted content is enabled.

It is possible to embed Moodle (content) in frames of web applications for content management systems such as Joomla. Potentially, this can cause security problems, which is why the Allow frame embedding parameter, which can be seen by going to Security | HTTP security, is disabled.

Moodle also comes with a Word censorship filter (go to Plugins | Filters | Manage filters). However, it also picks up words within words, which doesn't make it that useful as it would mark valid terms, such as sextant, sparse, and altitude. You can either enter additional words and phrases in Settings of the filter or edit the badwords language string in filter_censor.php (careful, this list is far from G-rated).

Blogging, tagging, and commenting are social networking tools that are popular in Web 2.0 environments. Blog entries, tags, and comments are harnessed for the purpose of searching, sharing, and performing other collaborative activities in order to match interests. The potential issue is that the content is visible to users who should not be able to share or view entries. Moodle has catered for this by providing a number of settings, which we have already dealt with in the Collaboration section in Chapter 9, Moodle Configuration. Here is a list of areas where the respective functionalities need to be turned on and off:

If you deactivate any of the mechanisms, tags, comments, and blog entries that are already on the system or kept hidden, they will reappear when the functionality is turned on again. In other words, there is no risk of data loss when turning the functionality off and then back on.

You might also consider creating a dedicated role on your system, for example, a Blogger role utilizing the moodle/blog:create capability. This will limit blogging to specific users only—those who have been assigned the new role. You can find more details on the Blogger role in the Moodle Docs at https://docs.moodle.org/en/Blogger_role.

Users who have access to Moodle are sometimes as much a threat as unauthorized users. If you have a site policy that all users (not just learners) must see and agree to when logging in to Moodle for the first time, you will have some ammunition when taking action against a user who has misused your system. The document, often referred to as an Acceptable Use Policy, should aim to adhere to the LARK principle—Legal, Appropriate, Responsible, and Kind.

You can specify the URL address of the text by going to Security | Site policies, which includes Site policy URL and a Site policy URL for guests entry. You will have to specify a URL that contains the policy text, which should be an HTML document. The file is often a publicly accessible URL, for example, a policy that is already available on your main website.

Once the site policy address has been specified, it has to be confirmed by each user the first time they log in to Moodle. If the policy is in any other format than HTML or plain text, only a link will be provided to the selected file. It is, therefore, not recommended to use PDFs or Word files.

While the site policy does not prevent any misuse, it introduces a psychological barrier and also protects your organization in case further action needs to be taken. Site policies allow users to understand the expectations of how to most effectively and appropriately use a site. While it often has a legal undertone to dealing with bad users, it can also teach new users about the social expectations of those using the site.

Moodle supports the scanning of uploaded files for viruses using ClamAntiVirus (ClamAV), which is an open source antivirus engine for Unix-based systems. Refer to http://www.clamav.net/ for details, downloads for different operating systems, and how to keep the virus definition database up to date. You need to install ClamAV on your system. Once installed, the scanner can be configured by going to Security | Anti-Virus:

There are two limitations of ClamAV: