hackforla / tdm-calculator

DTLA Hack for LA is partnering with Los Angeles Department of Transportation (LADOT) to develop a Traffic Demand Management (TDM) calculator tool. This tool will help planners at LADOT and real estate developers to meet the Los Angeles’s Mobility Plan goals by 2035.
https://tdm.ladot.lacity.org
GNU General Public License v2.0
45 stars 28 forks source link

Investigate and Evaluate Suspicious Logins and Projects in Production Environment #1360

Open entrotech opened 1 year ago

entrotech commented 1 year ago

Dependency

No New Threats detected, this issue will be revisited when a new threat is detected.

Overview

On 4/19, we noticed that the Security Admin screen in production was showing several obviously fake registration attempts (see screenshots below). A few of these registrations also went so far as to create a few projects as well, meaning that they confirmed their email and created and saved projects.

Action Items

Resources/Instructions

image

image

image

image

Here is a list of all the existing projects in production - aside from the projects entered by LA DOT, Ebi Imaf, Patrick Gibson, most of them appear to be created by questionable users:

image

image

image

entrotech commented 1 year ago

For the suspicious logins: The two with email addresses *@wearehackerone.com are from people that are hacking for security testing purposes (see http://hackerone.com). Presumably they are practicing penetration testing skills and possibly looking for bounties on bugs they find.

The ones where they supply characters like <,> in the email or name are malicious simple attempts to see if they can inject scripts into form inputs to execute code on our site. Since we sanitize all form inputs, these are not really a threat, other than creating accounts that are clearly not legitimate. We could do some input validation that rejects inputs with such characters in the first and or last name.

The fact that some email addresses are not even formatted like email addresses (with a @ in them somewhere), indicates that some attacks are not through the registration form itself, since the form validates email format. Instead, they are attacking the Web API endpoint, and we need to implement email validation in that Web API request validation. Though we did recently implement partial Web API validation, including the registration endpoint, it only checks that the email supplied is text, and does not verify that it looks like a valid email as well.

The fact is that the application is open to the public, and anyone can register as a regular user and save projects, so we are likely to see a number of questionable user registrations and created projects, some of which might be benign potential users experimenting with the application, while others will be malicious.

I don't see any evidence that the questionable activity created any accounts with elevated privileges that would reveal or corrupt other users' data, or compromise the application integrity.

We should probably discuss some additional features that allow an administrator to "clean up" erroneous accounts and projects, like:

agosmou commented 1 year ago

We'll need to consider overall security standards and and security testing needs https://github.com/hackforla/tdm-calculator/issues/1364

Helpful Links: https://owasp.org/www-project-proactive-controls/ https://owasp.org/www-project-top-ten/

https://owasp.org/www-project-application-security-verification-standard/ https://github.com/OWASP/www-project-proactive-controls/blob/master/v3/OWASP_Top_10_Proactive_Controls_V3.docx https://github.com/OWASP/ASVS/tree/v4.0.3#latest-stable-version---403

agosmou commented 1 year ago

@azajzon @entrotech

I took a look at this. Here's some initial thoughts. Let me know if we're aligned.


  1. I think the first step for now is to add a RegEx at the register Schema and validate entries for emails and passwords by hand tdm-calculator/client/src/components/Authorization/Register.js
  2. There are also some libraries I'll look into such as formik and react-hook-form
  3. We should also validate on the server side before storing the credentials in the db

Other measures to consider:

agosmou commented 1 year ago

PR to address this ready for review

agosmou commented 1 year ago

Possible Attacks:

agosmou commented 1 year ago

Leaving this Open per conversation with John Darragh on 7/19

ExperimentsInHonesty commented 4 months ago

@entrotech discussed with John at 3/21, that there are some new types of threats, and he will document in this issue so that the issue can be reprioritized.

ExperimentsInHonesty commented 4 months ago