When building an online assessment site that let students take the examination via their own devices (but they are all in the same room during the examination), what kind of security vulnerabilities must the online assessment site consider?

I need a list of some possible security issues, scamming acts, etc to consider. For example, for the sake of money, one student A is paid by another student B to login with B's credentials and to do the examination.

How to prevent each issue from happening is also welcome!

closed as too broad by Steffen Ullrich, Jedi, Xander, Xiong Chiamiov, crovers Jul 10 '17 at 2:22

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    You are asking for a potential list of all the application logic that could be abused. This is far too broad to be answered, especially with no experience with the application. – schroeder Jul 8 '17 at 23:15

I need a list of some possible security issues

Could be almost anything on this list. Just to select some from the top ten list on owasp:

  • Injection -

    Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

  • Broken Authentication and Session Management -

    Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws.

  • Cross-Site Scripting (XSS) -

    XSS can occur whenever an application accepts untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user supplied data. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

  • Broken Access Control -

    Restrictions on what authenticated users are allowed to do are not always properly enforced. Attackers can exploit these flaws to access unauthorized functionality and data, such as access other users' accounts, view sensitive files, modify other users’ data, change access rights, etc.

  • Security Misconfiguration -

    Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, platform, etc. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

  • Sensitive Data Exposure -

    Many web applications and APIs do not properly protect sensitive data. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

  • Insufficient Attack Protection -

    The majority of applications and APIs lack the basic ability to detect, prevent, and respond to both manual and automated attacks. Attack protection goes far beyond basic input validation and involves automatically detecting, logging, responding, and even blocking exploit attempts. Application owners also need to be able to deploy patches quickly to protect against attacks.

  • Cross-Site Request Forgery (CSRF) -

    A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. Such an attack allows the attacker to force a victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

  • Using Components with Known Vulnerabilities -

    Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

  • Underprotected APIs -

    Modern applications often involve rich client applications and APIs, such as JavaScript in the browser and mobile apps, that connect to an API of some kind (SOAP/XML, REST/JSON, RPC, GWT, etc.). These APIs are often unprotected and contain numerous vulnerabilities.

I think the main ones you should focus on are injection and cross site scripting.

  • I don't know the correct terminology, probably "jockey" in which a student A is paid for helping another student B to accomplish the examination that B must do. For example, in the middle of the exam, the student A and B login using B and A credential respectively. Is it possible to prevent such scam? – Artificial Stupidity Jul 8 '17 at 16:57
  • You could do something like only allow the account to be logged into from one IP address. In this way, user B would have to be using user A's device to authenticate the login – Joe Jul 8 '17 at 17:02
  • 1
    IP cannot be tempered? – Artificial Stupidity Jul 8 '17 at 17:21
  • @SinglePackAbs 'proxy' is the term you are looking for – schroeder Jul 8 '17 at 23:13
  • @SinglePackAbs Student B could open a tunnel for student A to use, and the student A would then be using student A's IP and device address (MAC) – schroeder Jul 8 '17 at 23:15

Not the answer you're looking for? Browse other questions tagged or ask your own question.