How can I ensure my Static Web App + SQL Database/Server isn't Phishing?

Robert Bogan 20 Reputation points
2024-03-25T22:06:44.7+00:00

I'm a new developer without a CS background, and I'm new to both Azure and hosting web apps. I apologize in advance for my own verbosity in giving details here - and for my own ignorance about what are likely basic tenets in securing both my user data and my database.

In all, my web app used:
An F1 App Service plan
An App Service (.NET + EF, using CI/CD with a private Github repo)
A Static Web App (React, CI/CD with Github again)
An SQL Server
An SQL Database (Basic plan)

Anyway, after my delight at finally hosting my first (highly ambitious) web app on Azure, it was mere hours before Google Chrome flagged my site as being a risk of phishing. The message was as follows:

"Dangerous site

Attackers on the site you're trying to visit might trick you into installing software or revealing things like your password, phone or credit card number. Chrome strongly recommends going back to safety."

My kneejerk reaction was to immediately delete the Static Web App I had deployed, although I imagine my panicked reaction was a wasteful and incorrect one! I'm glad it occurred a few hours, rather than a few months, after deployment - and before any future employer views it (it's a real portfolio app)!

Although I'm embarrassed at having been flagged (and I can see some red flags having written in more detail about it below), I'm posting this question so any future learners can benefit from any advice given. I'd welcome any advice on the correct way to remedy the issue Google has flagged, and to ensure the next deployment of my site is secure for users.

The web app is essentially a cross between Anki and a quiz application. In the app, users will click on answers - although a lot of detailed information related to each question is pulled from the database for users to see.

There are five POST requests that can be made by the user to the database. Two of them are registration-related. Indeed, the only typed information a user can enter is an email and password in the Sign Up and Log In components. Two of the other three POST requests are to indicate whether a question in the app was answered correctly (and updates both the 'Next Review Time', 'Correctly Answered', and 'Number Of Attempts'.) The final POST request simply resets the 'Correctly Answered' and 'Number Of Attempts' in one model in the database.

I feel this is significant too: I can connect to the SQL Server from my local SQL Server Management Studio. I was using this to check whether I could add myself as a new user. (And to make sure the databases in the app are populated correctly). Essentially, I think the phishing might be linked to my being to view a user email! If a user were to sign up, then in my local SQL Server Management Studio, I can view the following information:
User Email, the PasswordHash, and PasswordSalt
I imagine the email being visible to me is the cause of the phishing/dangerous warning as flagged by Google, although I'm really not sure.

In any case, I'll finally ask the question:

  1. What steps should I need to take to ensure my future deployment is completely free of phishing?
    In addition, will I need to change or remove the 5 existing 'test' users that exist in my database? (Indeed, will I need to completely replace the SQL database with a new one?)

Thanks in advance for any help.

Azure App Service
Azure App Service
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
7,902 questions
0 comments
Accepted answer
  1. SnehaAgrawal-MSFT 21,691 Reputation points
    2024-03-26T08:25:06.28+00:00

    @Robert Bogan Thanks for reaching here! How to further protect your App Service app from threats-

    1. Secure your apps with HTTPS-
    2. To secure your app against all unencrypted (HTTP) connections, App Service provides one-click configuration to enforce HTTPS.
    3. By default, your App Service app accepts requests from all IP addresses from the internet, but you can limit that access to a small subset of IP addresses
    4. Azure App Service provides turn-key authentication and authorization of users or client apps
    5. When authenticating against a back-end service, App Service provides two different mechanisms depending on your need: Service identity, On-behalf-of (OBO**)**
    6. Connectivity to remote resources
    7. When your app connects to Azure resources, such as SQL Database and Azure Storage, the connection stays within Azure and doesn't cross any network boundaries. However, the connection goes through the shared networking in Azure, so always make sure that your connection is encrypted.
    8. For web workloads, we highly recommend utilizing Azure DDoS protection and a web application firewall to safeguard against emerging DDoS attacks.

    For details- suggest you to refer this detail document link- https://video2.skills-academy.com/en-us/azure/app-service/overview-security

    Hope this helps, Let us know.

    1 person found this answer helpful.
    0 comments

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. hossein jalilian 8,080 Reputation points
    2024-03-25T22:41:40.4633333+00:00

    Thanks for posting your question in the Microsoft Q&A forum.

    To mitigate the phishing risk and guarantee secure future deployments:

    1. Implement proper authentication and authorization mechanisms to protect user credentials.
    2. Encrypt sensitive data such as passwords to prevent unauthorized access.
    3. Use HTTPS to encrypt data transmitted between the client and server, ensuring data integrity.

    Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful

    0 comments
  2. Nick Askew 5 Reputation points
    2024-09-14T06:23:56.94+00:00

    Hmmm, this happened to me. I have created a really simple site (it's based on React) that's hosted in an Azure Static Web App. The site consists of three pages.

    The home page is more or less just the normal Vite + React template but I've added a link to two pages.

    • /login/ takes you to a page where you can choose how to login or logout
    • /calendar/ takes you to a page representing semi private information

    The login page simply has three links, one to login with Extra ID, one to login with GuitHub, and the final one is supposed to log you out (which does not work, but that's another issue).

    The calendar page is meant to be restricted to authenticated users. There is an entry in staticwebapp.config.json that seems to work nicely. If you try to visit the page before you are logged in then it gives a 401 (not pretty but it means the page is protected). If you log in then visit the page you see some text that represents my fake private info.

            {
            "route": "/calendar/*",
            "allowedRoles": ["authenticated"]
        }

    So I visited the SWA from Chrome and on trying to log in with Extra ID it came up with a big red page saying it was dangerous. I backed off and used GitHub instead but the URL bar still displayed dangerous in red next to my url. I tried the same in edge an had no problems (although the logout still does not work). I tried again from chrome and it worked again initially but as soon as I clicked on the link to log in with Entra ID it gives a huge red Dangerous Site alert again.

    I'm confident most of this was working perfectly yesterday. The urls for Entra ID, GitHub, and logout came from this article https://video2.skills-academy.com/en-us/azure/static-web-apps/authentication-authorization

    0 comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.