Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Looking for advice

Status
Not open for further replies.

G12Consult

Programmer
May 12, 2016
77
AU
Hi,

I have a webform (asp.net) which I want clients to complete, which will then populate my SQL tables.

However, this form is to be completed before they become a client so the form will be hosted outside of the authenticated area.

Its like a client fact find. Get information about the client, save it to the db, then assess them and if they pass, we make them a client, create a login etc and transfer the information to final tables.

What would be the best approach to handle this with unauthorised users populating tables in a SQL table with obvious security concerns in mind.

Thanks
Andrew
 
You never have any direct database access in any webpage, whether used by guest or client anyway. If you do, you do that part wrong or have a wrong understranding which parts of your ASP.NET code run server and which clientside.

For example, Javascript accessing databases always is meant for a serverside NodeJS and not for a browser client making a database connection.

There are no direct security concerns as your database access goes from your server-side ASP.NET script into the database, what you need to care about is to sanitize input and ideally use SQL parameterized, if creating dynamic SQL know what you're doing and in which ways you can be sure that doesn't allow SQL injections to take place.

Part of the security also is, your SQL connection isn't using users like @root (MySQL) or SA (MSSQL) or in general an administrative user, any website scripts only need enough permission to a database to perform necessary DML (insert/update/delete, maybe even structure your data to never let web application code DELETE records), call stored procedures, but no granted permissions for DDL language (CREATE/DROP/ALTER).

There's more to that to say in a single forum thread, besides SQL injection attacks can also make use of the way data inserted is displayed again perhaps even in other areas of your website, injecting Javascript to execute when some other user views a post, for example. So if you have serious doubts you know enough at least find someone doing security checks, a pentest (penetration test) of your site, for example and maybe also code reviews.

You can't learn everything you need to know within a few hours or weeks or even months. I also just gave top bullet points here.

Bye, Olaf.

Olaf Doschke Software Engineering
 
I would create a separate database (on a separate server) for your prospects/leads. If/when they are qualified, run an export process to export to flat file records, transfer the file to the production server, and then import those into the production system. That prospects/leads database does not need to be SQL Server as long as it can export to a file (Access, for instance).

==================================
advanced cognitive capabilities and other marketing buzzwords explained with sarcastic simplicity


 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top