• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Web Security for Web Developers

sao123

Lifer
So I have been making data driven Enterprise ASP.net Webforms websites (Front and back end) for a few years and am pretty fluent with both ASP.net and soemwhat even with Javascript/Jquery.

However all of my websites up till now have been on our companies intranet (completely isolated from internet traffic).

One of my upcoming projects is to build an external facing website on the internet, so I am looking for some resources for developers in the area of security.

So I am looking for a website with tips for hardening a website from a developers point of view. We dont handle the IT side of things, we have server engineers for that (but still good information for the developers to understand)...

Looking for items such as
How to prevent XSS attacks, Injection Attacks, encrypting the connection string within the web.config file, etc etc.
 
Never display un-sanitized user data.

Never send un-sanitized user data to the database. Or, better still, parameterize your queries. (But be careful with your parameterized data if it's not sanitized!)
:thumbsup:
OK, you lost me there. 😕 Any ASP.net experts around?
Well, googling the phrase turns up pretty decent results. But I'd examine if it's fully necessary in the given instance before doing it. If this is a web server with limited access (as in, only people with specific credentials can log into the box/access the file structure on the network) it wouldn't seem entirely necessary.
 
security is one area i wish i knew more about. thankfully the other cofounder who is also a developer is pretty much a security expert, so he has evaluated all areas of our app that need to be made more sercure before we can launch. alot of the calls i have made he is having to modify in order to make them secure.
 
encrypting the connection string within the web.config file, etc etc.

Well the connection string I see no point in encrypting because I assume you trust your web server? Of course it should not be readable from the website but encrypting it is seems pointless unless you don't trust server admins???

What more important is to use a restricted user that has only the privileges needed. For example it should not be able to run DDL statements.

EDIT:

And use https. http is never secure.


https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet
 
Last edited:
security is one area i wish i knew more about. thankfully the other cofounder who is also a developer is pretty much a security expert, so he has evaluated all areas of our app that need to be made more sercure before we can launch. alot of the calls i have made he is having to modify in order to make them secure.

Same here. I just never needed to be a security expert given the projects I've worked on. But with the one I'm working on now, I definitely will as the alternative isn't good. Ugh.
 
Well the connection string I see no point in encrypting because I assume you trust your web server? Of course it should not be readable from the website but encrypting it is seems pointless unless you don't trust server admins???

What more important is to use a restricted user that has only the privileges needed. For example it should not be able to run DDL statements.

EDIT:

And use https. http is never secure.


https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet


Well I heard its done 1 of 2 ways... either the entire web.config is encrypted or the connection string is encrypted.
the purpose is that if your web.config ever got exposed (shouldn't happen) that your Service Account passwords are not plain text stealable...
 
Well the connection string I see no point in encrypting because I assume you trust your web server?

This is actually the wrong way to think about it. It's not about trust, you have to assume that your server will be compromised. Even if it's not publicly accessible you should still assume it (it's extremely difficult to have a completely isolated network/computer). What you want is defense in depth.

Some quick googling suggests that Microsoft's own documentation suggests that best practice is to encrypt.

the purpose is that if your web.config ever got exposed (shouldn't happen) that your Service Account passwords are not plain text stealable...

Just assume that it will. Makes "decisions" like this much easier.
 
Last edited:
This is actually the wrong way to think about it. It's not about trust, you have to assume that your server will be compromised. Even if it's not publicly accessible you should still assume it (it's extremely difficult to have a completely isolated network/computer). What you want is defense in depth.

Some quick googling suggests that Microsoft's own documentation suggests that best practice is to encrypt.



Just assume that it will. Makes "decisions" like this much easier.

If the attacker has server access to an account that can read the directory web.config is in, then you are redactedanyway. Now I'm not a .net expert. Can you elaborate on how this works at all? The connection string must obviously be readable by the application and hence the application must be able to decrypt the string?

So this means the key is either also on the server on in code and in case of .net it's trivial to then get the key out of the code (decompile). Yes, it's extra work for the attacker but it doesn't add any real security on top.




No profanity in the tech forums.


esquared
Anandtech Forum Director
 
Last edited by a moderator:
If the attacker has server access to an account that can read the directory web.config is in, then you are redactedanyway. Now I'm not a .net expert. Can you elaborate on how this works at all? The connection string must obviously be readable by the application and hence the application must be able to decrypt the string?

So this means the key is either also on the server on in code and in case of .net it's trivial to then get the key out of the code (decompile). Yes, it's extra work for the attacker but it doesn't add any real security on top.

Salting + encrypting doesnt make it impossible, but its still more secure.

http://weblogs.asp.net/jongalloway/encrypting-passwords-in-a-net-app-config-file
 
Last edited by a moderator:
Back
Top