Phishing Website Detection System source code

The problem it solves

People need a quick offline way to judge whether a web address looks like phishing before they click it, without relying on an internet service or visiting the site.

Project topic: Design and Implementation of a Phishing Website Detection System

Who uses it

What it does

• Run a phishing check

  The user pastes a web address. The system checks it against the active weighted rules, calculates a score and verdict, and shows the fired warnings as reasons. The check is saved to the user's history.

• View and export check history

  The user sees their own saved checks in a paginated list and can open any past result. A CSV download of their checks is available.

• Manage detection rules

  The administrator lists the warning signs, switches them on or off, changes their weights, and sees the rule version. Old checks keep the rule version and reasons from when they were run.

• Manage user accounts

  The administrator creates user accounts, disables them, and resets passwords. The administrator can also view all checks across all users.

Screenshots

Screenshots of the running system, taken by our checks. The records are sample data and are labelled so on each page.

Database tables

• usersStores user accounts and their role. Passwords are hashed with Werkzeug.id, username, password_hash, role, active
• rulesStores the warning signs used by the detector. Each rule has a weight and an on or off switch.id, name, description, weight, active
• rule_versionsRecords a short label for the rule list as it changes over time. Each check stores one label.id, label, created_at
• checksStores every phishing check that has run, with the score, verdict, stored reasons and rule version.id, user_id, url, score, verdict, reasons, rule_version, created_at, sample

Technology

• Python. Readable, and already supported by the project kit and run.bat.
• Flask. Small standard framework for a single laptop demonstration.
• Jinja. Comes with Flask, so templates extend base.html with no extra tooling.
• SQLite with sqlite3. One local file, works offline, and parameterised queries keep SQL safe.
• Bootstrap (local vendor files). Works offline and students can read the markup.
• Chart.js (local vendor files). Offline charting with no CDN if a student adds one.
• Werkzeug security. Built into Flask and avoids plain-text passwords.
• Flask-WTF CSRFProtect. Simple standard protection for local and classroom use.

How to run it: running a Python project on Windows. Not sure which language to pick? Python or PHP.

How it was tested

19 of 19 tests passed, 14 of them automated. The system was also installed from scratch and every screen was opened as the right kind of user before it was accepted.

What it does not do

• The detector judges the address text alone. It never loads the page, so it cannot see the page content, forms, images or links.
• It uses no live blacklist and no online service, so it cannot know about a brand-new site that is not yet reported.
• The 'recently registered domain' rule uses a small local list, so it is a simulated indicator, not a real WHOIS lookup. The page and guide label it as simulated.
• Rules are simple keyword and host checks, so a well-made phishing address can still score low.
• The app runs on one laptop for one user at a time. The session secret has a development default and must be changed before any shared use.
• The demonstration logins use known passwords and are for local practice only.
• The tool does not block, filter or quarantine anything; it only reports a verdict for an address the user types.