Skip to main content

Security Features

Security

This page describes how we secure our code that is not vulnerable to anything.

Security of web applications

Secure web app requirements​

We provide maximum level of security for web applications:

  • Separate administration backend
  • No sensitive information stored in web application.
  • Communication is encrypted using SSL.
  • Log all user actions.
  • Server applications and database servers are completely separated.
  • No files uploaded by users on server Instead it is loaded directly to AWS S3 bucket.
  • Validate user identity and actions via separate IdentityServer for each transaction using JWT.
  • Always keep every software up-to-date.
  • No 3rd party browser extensions recommended.

Roles and Permissions of The Different Account Types


 

image.png


Security measures to avoid security vulnerability.​

  • Unauthenticated access.
  • Unauthorized access.
  • Cross-site request forgery (XSRF).
  • Cross-site scripting (XSS).
  • SQL injection.
  • Command-line injection.
  • Data-loss.
  • Confidential information leakage.
  • Session fixation.
  • Denial of service (DOS).
  • Brute-forcing login.
  • Insecure configuration management.
  • Buffer overruns and other platform weaknesses.


Unauthenticated access

BeED will not allow any user without proper authentication. We authenticate user with the following

  1. Through BeED Auth System In-built
  2. Gmail Auth
  3. Facebook Auth
  4. Apple ID Auth

Unauthorized access

BeED will always check the permission for any given user before performing any actions.

Roles and capabilities​

BeED has a flexible roles system, build around the concepts of

  • roles- Roles let administrators and teachers control which users get which capabilities in which contexts. Different role assignments and role definitions give administrators a lot of flexibility.

Groups​

Moodle also allows users to be put in groups. Different groups may have access to different activities, and may or may not be able to see the actions of people in other groups.


Cross-site request forgery (XSRF) 

Session key​

The most important protection is the concept of a sesskey, short for session key.

When you log in, BeED adds a random string to your session. Whenever it click a link or a button to perform a significant action, it adds the sesskey value to the submitted data. Before performing the action, it checks the sesskey value in the request with the one in the session, and the action is only performed if the two match.

Cross-site scripting (XSS)

BeED need teacher and student to use CKEDITOR (Richtext box) to create and answers content to questions. To tackle Scripting XSS we use technique called Escaping output. That will replace any < character with &lt; and soon. If that is done, there is no way that the input can be interpreted as JavaScript. 


SQL injection

BeED, completely avoid the dangerous process of building SQL by concatenating strings. In BeED the SQL would look like

UPDATE m_user SET lastname = ? WHERE id = ?;

and then we would pass an array of values [$lastname, $id] to the database along with the SQL.


Command-line injection

BeED does not use any shell commands.

Data-loss & Ransomware

BeED avoids the major cause of data-loss such as 

  • Unauthenticated access
  • Unauthorised access
  • Cross-site request forgery (XSRF)
  • Cross-site scripting (XSS)
  • SQL injection
  • Command-line injection

Also it takes the backup of the data every 1 hour in to a secured S3 location in case if required to retrieve the accidental delete of data.

Configuration information leakage

BeED makes it easy for you to hide error messages, or only have them sent to your log files. 

BeED records all the error in to log files, which reveals almost everything about your sever, but only if you are logged in as admin to the server.

Denial of service (DOS)

Most of the really expensive operations in BeED (for example completing a quiz) are only available to authenticated users, so by logging all requests from authenticated users, BeED helps administrators identify culprits.

There are various tools that we use (for example, firewalls, proxies) from AWS to limit the number of requests coming into our server. 

BeED Monitor performance on our servers 24x7, so we know what normal load looks like, and that we have enough hardware to cope with normal fluctuations in load.


Brute-forcing login

BeED also counts failed login attempts and lock the user if there are too many attempts.

There are system settings that we enforce a minimum level of complexity for passwords, for example, by insisting on a minimum number of characters.


Buffer overruns and other platform weaknesses

BeED leverage best software/open source available for cache such as redis to avoid such weakness in the system.


No Comments
Back to top