Skip to content

Developing a PHP Project to use all the basic PHP essentials and Exploring Threats for Web Development and its prevention.

Notifications You must be signed in to change notification settings

Tanvi-Jain01/MCQ-PHP

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

15 Commits
 
 
 
 
 
 
 
 

Repository files navigation

MCQ-PHP

This repository is made to get familiar with all the concepts of a website like: cookies, sessions, CRUD operations, Login, register, feedback.

User Interface:https://github.com/Tanvi-Jain01/MCQ-PHP/#user-interface
Database:https://github.com/Tanvi-Jain01/MCQ-PHP/#database
Testcases:https://github.com/Tanvi-Jain01/MCQ-PHP/#testacases
Security:https://github.com/Tanvi-Jain01/MCQ-PHP/#security
Threats:https://github.com/Tanvi-Jain01/MCQ-PHP/#other-threats
Prevention: https://github.com/Tanvi-Jain01/MCQ-PHP/#prevention
Q/A: https://github.com/Tanvi-Jain01/MCQ-PHP/#how-to-test-your-web-design-for-xss-and-sql-injection
Future Aim:https://github.com/Tanvi-Jain01/MCQ-PHP/#future-aim

User Interface:

Homescreen

image

Registration

image

After registration

image

Login

image

After succesful login cookie has been saved, so that the user dont have to enter again.

image

Check Marks

image image

Get Print

image

Start the Test

image

Get result instantly

image

Unregister

Enter your credentails and you will be unregistered.

image


Database

Register schema:

image

feedback schema:

image

Result schema:

image


Testacases:

Registration

If email already exists

image

if password doesn't match

image

password should be 8 charachter

image

Testcases in Login:

image

Testcases in Checking marks

image


Security

Sanitizing input

image

password encryption

image

POST method

image

Why POST Method?

Some notes on POST requests:

POST requests are never cached POST requests do not remain in the browser history POST requests cannot be bookmarked POST requests have no restrictions on data length Data is not displayed in the URL Data will be re-submitted (the browser should alert the user that the data are about to be re-submitted)


Other Threats:

SQL Injection:

SQL injection is another technique that exploits a web application's vulnerability to execute malicious SQL statements on the server-side database. These statements can manipulate, delete, or extract data from the database, or even gain access to the server itself. SQL injection can occur when a web application accepts user input that is not properly sanitized or parameterized, and then uses it to construct SQL queries.

How to prevent SQL injection?

One of the best ways to prevent SQL injection is to use prepared statements or parameterized queries, which separate the user input from the SQL logic and prevent any malicious input from being interpreted as part of the query. This means that any potentially harmful characters, such as ', ;, or --, are treated as literal values and not as SQL commands. Another way to prevent SQL injection is to use stored procedures, which are predefined SQL statements that are stored on the server and can be invoked by the web application with specific parameters.Another way to prevent SQL injections is to use an allowlist for allowed values

XSS:

XSS stands for cross-site scripting, a technique that allows malicious actors to inject client-side scripts into web pages that are viewed by other users. These scripts can steal cookies, session tokens, or other sensitive information, or redirect users to phishing or malware sites. XSS can occur when a web application accepts user input that is not properly validated or encoded, and then displays it as part of the web page.

Prevention:

1) Sanitize the user input.

2) Encryption of database names and columns while deployment.

3) Give minimum access to users.

4) Never trust User Inputs.


How to test your web design for XSS and SQL injection?

One of the easiest ways to test your web design is to use a tool like OWASP ZAP, which is a free and open source web application security scanner that can detect and exploit XSS and SQL injection flaws. You can also use manual testing techniques, such as entering malicious input in the web forms or the URL, and observing the response of the web application.


Which's safe, Session or Cookies??

A session stores the variables and their values within a file in a temporary directory on the server. Cookies are stored on the user's computer as a text file. The session ends when the user logout from the application or closes his web browser. Cookies end on the lifetime set by the user.

We can store as much data as we want within a session, but there is a maximum memory limit, which a script can use at one time, and it is 128 MB. The maximum size of the browser's cookies is 4 KB.

Sessions are more secured compared to cookies, as they save data in encrypted form. Cookies are not secure, as data is stored in a text file, and if any unauthorized user gets access to our system, he can temper the data.


Future Aim

1) Include time of Attempts

2) Include captchas

About

Developing a PHP Project to use all the basic PHP essentials and Exploring Threats for Web Development and its prevention.

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published