Firefox/Feature Brainstorming:Security

« Firefox/Feature Brainstorming

Specific features	References
Bookmarklets Use of Javascript bookmarks should be denied if the user attempts to use them while the browser has established a secure https connection (to prevent malicious javascript injections). As of 2.0.0.1 Firefox allows javascript bookmarks to attach external, third-party, scripts to the page during a secure connection without any warning creating a gaping security hole. The user should be warned when attempting to bookmark javascript code. The user should be warned (with disable future notices) when using javascript bookmark code which attempts to attach external scripts to the document.	n/a
An additional strategy for whitelisting An additional strategy for whitelisting could be that we have a universal directory maintained by people. This directory will have the pages where the user can enter the ID and password for that site. FF could show the user by means like address bar colour that he is entering the right site. So we have people, like citibank, paypal, yahoo, indiatimes, rediff etc., giving the pages where the user can logon from, to this directory. This will help user overcome the recent flaw discovered in IE and FF as well as provide better phishing protection.	Phishing protection ( below) The description of the flaw can be found here [1]
General mechanism for blacklisting and whitelisting ability to allow/disallow sites the usage of each and every "abusable" function each and every plugin (java,flash,pdf,multimedia,_each_and_every_) (java)script (general/sub-functions (->folding)) blink, animated gif/jpg/png/whatever automatic reload (meta http-equiv="Refresh") cookies etc. etc. allow temporarily one specific URL in one specific (the current) window (means tab) one specific site/IP-range in one ... specific site/URL in all open tabs	- look for blacklist/whitelist below - Adblock extension - NoScript extension
AJAX Ability to disable XMLHTTP* javascript calls entirely. AJAX rocks, but it could be a potential security threat (for example, I enter in my credit card number, and then think better of it. But too late! The asynchronous javascript has already sent my details back to some nefarious web site before I clicked "submit"). Ability to see graphically if asynchronous calls are being made on my behalf (mabye add a flashing icon to the status bar?) Ability to selectively allow/disallow certain sites from using AJAX.	n/a
Surf by IP protection Two new security options, which should be checked by default... [ ] Disallow visiting sites by IP address (IP anywhere in the URL) [ ] Allow local LAN IPs (192.168.x, etc. for getting to your home router, access-point configuration pages, or some corporate intranets) By using these security options, you will quickly kill off all the "lasy phishers" who don't setup or register a domain-name for thier false site.	n/a
Download actions -- don't download Under Options/ Content / File Types / Manage dialog (called Download Actions) -- add option "don't download files like this". At the moment if the plugin exists, I can only select which application will open the file, but the file will always be downloaded. It should be possible to disable handling and downloading of some file type.	n/a
Security preferences Automated user preference auditing with user notification of potentially problematic preference settings.	n/a
Phishing protection Make it easier to report phishing sites Implement a phishing filter that learns automatically Consider intergration with something like PhishTank [2] Multi-provider support for local list checking (depending upon provider demand) new approach: allow certificate whitelisting. Organizations could sign certificates not just (as today) in order to confirm the identity but to confirm that a web site belongs to the "good guys". Users could mark the certificate of such an organization as trustworthy. When displaying a site which has been approved that way the browser should mark it somehow (a green address field e.g.). This is just an infrastructure idea. If Firefox supports that people will start to offer whitelists. Whitelisting makes more sense than blacklisting - it's easier and safer. There are rather few web sites which are potential phishing targets so it should work. Additionally, rather than just using a green address field: once a website is verified as trusted, the domain matches the certificate, the trusted domain's logo could be requested from a standard location on the trusted domain's server. This logo should be of a standard size and displayed near the browser acitivity icon. The intention is to give the impression of a holographic imprint of authenticity. Logo's should be tracked by root certificate authorities to ensure no two are similar.(Randomly 14:43, 7 December 2006 (PST)) new approach: bi-directional registrations. When a user registers with a site, the browser submits a request to the site to send back a password (let's name this password the site password). This password is kept by the browser in the password list. When the user tries to login into a site, the browser sends the user password to the site and the site sends back the site password; then the browser compares the site password with the one stored internally and if they don't match, the site is not displayed in the browser. With bi-directional registration, both sides (the user and the site) must submit a password to each other in order to view the site. A phishing site can not know the site password (unless the original site is compromised during registration), so users are safe, even in the presence of identical web pages or domain names. This approach requires a little more work from the web applications that must generate, keep and send site passwords. But from the client side, it is a flexible solution that can be automated at browser level.	certificate whitelisting - in German [3]
Safer Browsing Like anti-phishing, but with a list of sites that are known or suspected of being a source of malware (virii, spyware, etc)	See bug 347849
Script execution Integrate script execution whitelisting Allow cross-site scripting between whitelisted sites (for mashups) Is this the right place for this request? Provide 'visibility' attribute for iframes defaulting to 'private', also allowing 'protected'. Private indicating child cannot access parents, protected indicating the first child may access parents.	NoScript bug 320522
Pop-ups Implement one-click viewing of blocked pop-ups Make printing popup windows possible Implement a way to block every pop-up window, regardless of the way it was requested. Let the user allow temporally show pop-ups for a certain site (like IE). The way it is now, makes a hard to visit a site just once.	- More on printing pop-ups
Secure Defaults/ No Security Pop-ups People find security popups just as anoying as pop-up advertisements. Completely move away from the "ask the user to do dangerous things" mentality. People are already getting annoyed with Vista constantly bombarding them with security questions, and are well trained to just click "yes/ok" [Dangerous!]. Use secure defaults, and only provide "notifications" whenever appropriate at the top of the screen (that do not require user intervention- but give the option to "allow" the potentially dangerous action). A major selling point of Firefox would be that it has no annoying popup (security or otherwise) messages.
Restricted Javascript Prevent window resizing Prevent hiding toolbar/controls Prevent capturing mouse events (overriding clicks, and obnoxious mouse-tracking scripts) Prevent floaters (or have some way to hide these layers) Prevent automatic form submission (or "Did you really want to submit this?") Trace window/panel with the history of form submissions and visited URLs, with the option of ask before submit everytime. Provide a way to prevent a browser window from being locked up by a Javascript loop which repeatedly produces a Javascript dialog, e.g. a "Stop script" button in Javascript dialogs (for instance : http://users.etu.info.unicaen.fr/~pbour/) Per-site javascript settings, i.e. allow users to choose to enable "move/resize window", "replace context menu" etc, on a per-site basis, instead of just a single global option. Please, PLEASE don't forget Intranet and Web Application usage scenarios when considering the Restricted Javascript proposal. There are countless weblications that depend on one or more of the above. If the Javascript restrictions are not (at least) configurable, and possibly defaulted to 'no restrictions' for local or LAN-accessed files, then those applications will break or mis-function. Jabbott 10:32, 16 October 2006 (PDT)	n/a
Cookies Add cookie whitelist funcitonality One-click block/allow cookies1 Allow cookies from sites (on request) remain persistant even after the browser has been restarted Allow session cookies per window/tab so that multiple logins can be had to services such as gmail/hotmail simultaneously.2 "Supercookies" Never accept cookies associated with invisuble images: single, pixel GIFs and so forth Extensions like "Extended Cookie Manager" allow you to enable or disable cookies for the current site. However, it is common that sites use redirection, and a different site for actual authentication. Something like login.google.com when browsing www.google.com. So, simple "enable cookies for this site" features are not effective. The "ask every time" cookie dialog box should have another checkbox: "Don't ask again". This is so you can deny a cookie, and not have many more dialogs pop up to deny. This would complement a "One-click block/allow cookies" feature. More granular cookie controls - allowing regex definitions of what cookies should be accepted or declined. Not just based on the source site but also on the contents of the cookie. E.g. I don't care what site it is from, I never want to accept a cookie that contains the string AD_ID, even if I accept other cookies from a site. Have an option to automatically allow session cookies, even if I asked to ask every time, like in Internet Explorer. The main use of asking every time is to be able to allow permanent cookies only for those sites you trust, and to make every one else to last only for the session. But session cookies will do it anyway, so it's a waste of time having to opt in each one. Cookie-Editor Support for non-"top-level" domains (e.g. don't allow cookies for .co.uk). In the "Cookies" dialog box, have a button named "Block Cookies" that removes a selected cookie and creates an entry in the "Exceptions - Cookies" dialog box that blocks cookies from that cookie's site. In the "Exceptions - Cookies" dialog box, right-clicking a cookie site causes a right-click menu to appear that allows you to change the cookie site status between "Block," "Allow for Session," and "Allow."	Fix cookie domain checks to not allow .co.uk 1 Like "CookieCuller" 2 Like CookiePie
Exploit Mitigation Please consider splitting all page rendering code into a seperate process running with reduced permissions, either using ACL on Windows, or as a seperate low-privilege user on Unix-style systems. Use IPC mechanisms to handle network interaction and requests to save files in non-sandboxed directories. Assume that a network deliverable attack will exist, please ensure that the worse that happens is that the rendering engine must be restarted. To secure a process on Linux, simply write to the /proc/self/seccomp file. The process will then only be able to communicate via existing file descriptors (be sure to close the X11 one) and existing shared memory regions. Only about four system calls are allowed for a process in secure mode: read, write, exit, and signal handler return. To secure a process on a domain/type enforcement system like SE Linux, use a separate executable for handling untrusted content. A separate executable is required so that the security system can wall it off, permitting only communication with the other components of the browser. (components being: separate UI, network, config file access, cookie access, cache access, other disk access)	For Windows samples see: User:SergioJ
Extension installation One-click to permanently add site to whitelist One-click to temporarily add site to whitelist for this session Third-party signing and authentication by Mozilla	Extension Blacklisting UI Spec
Virus/Malware protection Intergrate a sandboxing feature automatically. (Like Sandboxie -http://www.sandboxie.com/) Integrate virus scanning and malware protection for retrieved content/files Integrated support for 3rd party Anti-virus scanners Firefox to run in a "Protected mode" like IE7/Vista (see the Sandboxing above) See Exploit Mitigation comment above.	n/a
Spoofing Employ some shared-secret anti-spoofing techniques1 Prevent content and scripts from being able to spoof or mimic protected chrome SSL auth required for send password This is an optional, but strongly recommended feature suggested during install Sending password with FORM.send or Javascript.Send check if the page is SSL encrypted and will display an error message if there's no valid SSL certificate. Do not allow adding "*" to FORM.edit field from Javascript (avoid spoof) This way a user will get warning when tries to log in to an unsafe service, like phishing sites. All sites with authentication should have valid SSL certificate or should be added to "safe to login" list.2 Add some indication of which site produced a Javascript dialog, to prevent dialogs appearing to come from another site in a tabbed session. Check digital signature of a web page based on some extended DNS records. That way if a site is defaced, it will be obvious. Note that SSL does not guard against defacement, but this will.	1 PassPet 2 details & discussion
Visualy showing server access Show every server access (by a moving icon), including AJAX access (see above) and streaming, for example, not only standard HTTP access.
New technology support Extended Validation Certificate support Integrated PGP/GPG to sign/encrypt/authenticate text (eg Web Mail)	Extended Validation defined by CA/B Forum; this is related to a suggestion further down titled "SSL Verification Levels"
HTTP authentication improvements Support for logging out of basic or digest HTTP authentication (RFC 2617 style) Implement a somewhat secure HTTP shared-secret authentication scheme based on SRP. The RFC2617 schemes are both very vulnerable to phishing. Show content of 401-unauthorized pages, and add widgets to login via forms instead of modal dialogs	See bug 355319
Keychain support for MAC OS X / KDE / Gnome Save passwords in the OS-level Keychain on OS X, so that passwords can be shared between Safari / FIrefox / Camino / etc. Ability to switch to external password manager like kwallet etc. and to disable firefox standard password manager	See bug 278343 and bug 309807
Parental Controls Filtering, prevent programs from being downloaded, keep sensitive information from being transmitted, monitoring, logging, etc. Should work with third party vendors to implement a set of baseline capabilities (that are somewhat commoditized) while providing awareness for higher value products and services.	n/a
SSL Verification Levels Certificate authorities offer a variety of different certificates. Some only check if the applicant has an Email (like admin or info) in the domain for which the certificate is requested. Some require the applicant to send in some proof of his/her identity. It would be nice to see the level of trust an ssl certicate has. Different Icons for different Levels of certificates would make my decision to trust a website easier. Certificate-Levels to think of: Domain validated, web of trust, Company identity validated, ...	n/a
Support StartTLS Without StartTLS, managing virtual hosts with TLS support is a pain (because it requires many IP addresses, for example). StartTLS support could make TLS use much more common.	http://www.ietf.org/rfc/rfc2817.txt
Support .hta files in IE a local .hta file is an html-application. It's like an html-file but has all rights on the local machine (read/write everything), so it's in fact a program. A .hta-file runs like a program in its own window, not in a tab.	http://www.ietf.org/rfc/rfc2817.txt
Highlight the URL domain name in the address bar using bold/underline or a different font size/color, so that the user can be sure that he is really accessing 'mydomain.com' instead of 'mydomain.com.phishingsite.com'. If this second phishing URL is inadvertently used, the browser therefore would highlight 'phishingsite.com' which would strongly hint at the user that the URL is wrong.
General tasks
Improve user notification of insecure browsing situations Rather than pop up annoying dialogs when a site has a bad security certificate, simply perform the encryption without showing the lock icon. (make the https site happy without bothering or misleading the user) Improve handling of digital certificates Improve phishing protection UI Improve overall security UI Improve pop-up blocking UI and options Implement a Security Center like Netscape 8.1	n/a
Integrated something like adblock.	n/a
Integrated mini-Firewall Integrate a plugin tool, which emulates some kind like a Firewall, like the "Foxie" plugin to IE, but of course, more powerful. Session manager A module that allow you, to save your session, restore, modify and lot of more things to do with them !! (Like Opera o MyIE). By Kaamos
Tweak Master Password options? Currently, the only way to secure the viewing of all passwords (Tools>Options>Security>Show Passwords) is to set a master password. Unfortunately, this master password must be entered every session, which effectively blocks a friend from browsing without having the owner of the master password nearby. I propose there be at least four options for the master password: Current (Enter master password at the commencement of each session) Delayed, entered on first need (Enter master password the first time any password is needed, but non-password surfing is unrestricted) Entered on each need (Enter master password the any time a password is needed, but non-password surfing is unrestricted) Master password is only needed to Show Passwords, but not to use them (equivalent to no master password, but protects unfettered access to plain-text passwords). Please indicate if this suggestion is better placed in UI. (Reasoning: this improvement [admittedly to the UI] would result in significantly greater security and increased used of master passwords.)	n/a