SchoolDay uses advanced security to protect user privacy and data. This includes:
SSL/HTTPS Full encryption to protect against data transferred between client and server.
We store and protect the privacy of passwords using a PBKDF2 algorithm with a SHA256 hash.
Cross site scripting (XSS) protection
Cross site request forgery (CSRF) protection
- CSRF attacks allow a malicious user to execute actions using the credentials of another user without that user’s knowledge or consent.
SQL injection protection
- SQL injection is a type of attack where a malicious user is able to execute arbitrary SQL code on a database. This can result in records being deleted or data leakage.
- Clickjacking is a type of attack where a malicious site wraps another site in a frame. This attack can result in an unsuspecting user being tricked into performing unintended actions on the target site.
Host header validation
- We use the Host header provided by the client to construct URLs in certain cases. While these values are sanitized to prevent Cross Site Scripting attacks, a fake Host value can be used for Cross-Site Request Forgery, cache poisoning attacks, and poisoning links in emails. Because even seemingly-secure web server configurations are susceptible to fake Host headers, Django validates Host headers against the ALLOWED_HOSTS setting in the django.http.HttpRequest.get_host() method. This validation only applies via get_host(); if your code accesses the Host header directly from request.META you are bypassing this security protection. For more details see the full ALLOWED_HOSTS documentation.
- Similar to the CSRF limitations requiring a site to be deployed such that untrusted users don’t have access to any subdomains, django.contrib.sessions also has limitations.
- We limit uploads in the Web server configuration to a reasonable size in order to prevent denial of service (DOS) attacks.
- No bulletproof technical solution exists at the framework level to safely validate all user uploaded file content, however, these are other steps we take to mitigate these attacks:
- One class of attacks can be prevented by always serving user uploaded content from a distinct top-level or second-level domain. This prevents any exploit blocked by same-origin policy protections such as cross site scripting. For example, if your site runs on example.com, you would want to serve uploaded content (the MEDIA_URL setting) from something like usercontent-example.com. It’s not sufficient to serve content from a subdomain like usercontent.example.com.
- Beyond this, applications may choose to define a whitelist of allowable file extensions for user uploaded files and configure the web server to only serve such files.
Additional security measures
- Our Python code is outside of the Web server’s root. This ensures that Python code is not accidentally served as plain text (or accidentally executed).
- To protect against brute-force attacks against the authentication system, we deploy a Django plugin or Web server module to throttle these requests.