I've read several places that ASP.NET are more secure than ASP Classic. But never seen any actual arguments of why.
Using a standard login system as an example.
The user sends a username and a password to the server via forms. This is done the same way in both languages. And in both languages the rest is done on the server.
Why choose ASP.NET over ASP Classic here?
As mentioned by ScottRFrost, Request Validation protects against XSS as default. Personally, I'd prefer to turn this off and develop an application to use output sanitisation insead (e.g. HTML encode output to web pages, or properly encode and escape output used in JavaScript). This approach doesn't restrict user input so it does not restrict application functionality in the way Request Validation does. e.g. It will allow HTML to be entered into a field which will be displayed on a webpage instead of interpreted by a browser (imagine a HTML developers forum that didn't allow HTML to be posted). If you use this method in ASP.NET, you would use a very similar approach to standard ASP development in terms of variable output to the page.
To answer your point, during authentication (validating a username/password combination) there is not much difference between Classic ASP and ASP.NET. ASP.NET provides some user controls that can be dropped into a page, and also provides the Membership Provider model, but essentially you have to implement the logic for this either way.
ASP.NET also has authoriazation compenents included as standard, so it is possible to restrict access to your whole application or certain URL paths from settings in the web.config fille. This guards against a developer forgetting to include authorisation checks on a per page basis. Any finer grained access checks will still need to be manually handled in ASP.NET though.
ASP.NET also provides specialised folders such as /App_Data that cannot be read via the web server. This gives a convenient place to store application related files that should not be read directly via HTTP. You can do this manually in Classic ASP, but you would need to either store this directory outside of the web root or you would need to set local folder permissions so that these files cannot be read by the IIS user.
To summarise, I would not say ASP.NET is inherently more secure than Classic ASP, except for the fact that newbie developers are less likely to create an XSS vulnerable website in ASP.NET.
ASP.NET includes features like Request Validation by default that limits some common script attacks. You can do it yourself in classic ASP, but in .NET it's default.
There may be may security issues. But I am concerned about one thing. It is about SQL injection. Asp.net has provided the facility of parameterized query and HTML encode decode technique. For more information click the link ASP.net security
Related
I have created a web site with asp.net 3.5 and SQL Server 2005 on the back end
We have created admin site for updating data in the database by using secure user account.
I working for live for some time.
After some times we found that some specific html tags are getting inserted into string fields of the database.
It seems some kind of attack
Can any one suggest me how to prevent from that attack.
What you have is probably a SQL injection attack that is being used to deploy a cross site scripting attack. However this may possibly not be coming from the asp.net application itself. By default ASP.NET web applications will turn on request validation which blocks posts that may look to be a cross site scripting attack (they will get a "dangerous request 500 error when posting HTML"). If you have turned that off then you're probably exposing yourself.
You should use an ORM like LINQ to Entities or at least be using parametrized queries for any SQL queries you are executing, this will go a long way in protecting you from SQL Injection attacks. You still have the issue however of cross site scripting. Take a look at the Microsoft AntiXSS library to ensure that you are protected.
The other problem you will have is with people internally or through another application that may be inserting into your database (if you're using it as a common database). For that the best you can do is to put a check constraint that fails when you match HTML on a regular expression. Check out this article on details.
I think this is a Cross-Site scripting attack.
You can set the "validateRequest" to "true" at the application level(in config), or set it at the page level in page directive.
Please read more here
You should always encode any input from the user to prevent cross site scripting and SQL injection attacks.Server.HtmlDecode and Server.HtmlEncode were there precisely for this reason.
On top of that, if you want to prevent Html tags altogether, scrub the input of the unwanted tags using a Regular Expression.
I'm working on adding a new webapp to an existing website. I've been directed to write the webapp in ASP.NET. The existing website is written in ColdFusion. For the most part, the ASP.NET webapp is completely stand-alone, but it needs to interact with the ColdFusion code in one important way - if somebody logs in to the ColdFusion site, we don't want them to have to log in again when visiting an ASP.NET page.
When someone logs in to the ColdFusion site, their username is stored in a cookie, along with a login token that can be looked up in our database. My .NET is a little rusty, so I'm having trouble visualizing how the ASP.NET code should use this data. I've already written a simple MembershipProvider that can be used to log in/out out the ASP.NET app using the data in our existing database tables, which are shared with the ColdFusion code.
What I'd like to know is - how can I make sure the ASP.NET app detects the cookies set by the ColdFusion app (I imagine they'd be sent to the ASP.NET pages, since everything is hosted on one domain), and automatically logs the user in using the MembershipProvider and Forms Authentication, using the credentials supplied in the cookie? I'm thinking that putting some kind of cookie check and log in function in the Global.asax file, set to run every page load for every page... but that seems kind of clunky. Also, do people still use the Global.asax file anyway? I had thought there was a more modern method.... Also, how can I manually log someone in using Forms Authentication and a custom membership provider? Currently my code allows the user to log in using the provided login control, but I'm not sure how to log the user in without them having to do anything.
Thanks in advance for any help. Looking over the MembershipProvider tutorials and the MSDN documentation it seems to me like the answer should be staring me in the face, but for some reason I just can't see it. Maybe not enough coffee....
Not sure if this is what you're looking for:
FormsAuthentication.SetAuthCookie("the username goes here",false);
Reference
I'm a CF developer ususally, but we had to do some integration with a .NET application recently and the way we approached it was to keep the CF and .NET sessions separate but ensure that login happened on both so when the user moved from one to the other they were still logged in.
So is there perhaps a way for you to hit your ASP.NET application with a request to login a user when you login using the CF application? Perhaps you could have an iframe on the page that you can load when the CF login is complete that holds a login service for the .NET app?
This way you would not need to worry about one app server reading the other app server's cookies, instead there would be two sets of cookies, one for ASP and one for CF.
Hope that helps!
The way I would approach it, is I would have a specific page that acts as a liaison between the CF and .NET layer. That page would implement your business layer and just check to see if the Cookie is there, if so read it in, do the lookup and login the user or whatever business logic that needs to be done. How would you accomplish the login/authentication, well that’s all based on your login/authentication code.
The only link I can offer is the basic of cookies in ASP.net
http://msdn.microsoft.com/en-us/library/aa289495(v=vs.71).aspx
Edit: found another link that might be helpful.
http://www.aspnettutorials.com/tutorials/network/cookies-csharp.aspx
I will be adding new pages and adding functionality to current pages.
I would basically like to use new technology and but I don't know how should I add it to classic ASP pages
In other words, can I <#--include--> an aspx page in Classic asp page? Or anything of that sort, may be creating a user control in ASP.NET and using it in classic ASP?
You shouldn't really add it to the existing classic ASP pages. You may want to perform a full (yet slow) migration from classic ASP to .Net. Otherwise, you may just simply want to add your new functionality in new pages completely. If you have a templated site, this may become a litle cumbersome because you will need to recreate those templates in .Net since mixing .Net and classic in the same file is not possible.
You could ultimately end up resorting to iframes, but this makes browsers goofy sometimes. If your application is dependent on session, you'll need to account for that because .Net can't access a classic session unless you stick to primitives (string/int/etc) and use an outside state provider (like SQL) to hold the data with a sessionid that can be passed.
Having a hybrid site is a very tricky prospect and not one to be taken lightly. Tread carefully or you'll really put yourself in a pickle.
EDIT: Partial Hybrid example description
We had a 700 or so page site to transfer from classic asp to Asp.Net 2.0. Many of the pages were allotted time to be completely transferred during a single project, but a few areas were unable to be refactored and had to be accommodated. We put together a master page architecture for the new .Net structure, data library and business objects library, and we began the transfer. In incorporating the classic asp pages, we determined we had a few needs.
Since master pages would control basic layout, menu, header, footer, we would need to remove these elements from any pages brought over.
New session requirements were incompatible with existing session capabilities.
Classic asp pages must still be required to obey .Net formsauthentication.
I solved these problems with the following solutions:
Our application is targeted at a specific customer, so we were able to determine browser requirements. This allowed us to employ an iframe to hold classic asp content/applications without worrying that the iframe would go crazy on us in Webkit or Firefox or whatever.
To accommodate the session requirements, we built a small encryption/decryption engine in .Net and in classic asp that enabled us to encrypt a "query string" to pass the session information back and forth. It wasn't super secure, just enough that the casual user would not be tempted to mess with data. In addition we had to build two translation files. The first translation file was a .Net library static method that would take the session data, extract the necessary pieces and create the query string. The second one was the classic asp version that was designed to read the query string, parse the data and create the session primitives directly.
Making the classic asp pages behave for .Net was a server management issue. To do this, using the formsauthentication attribute protection="All" is supposed to be sufficient, but I found it still did not cover items that had other handlers anticipated. So I added a wildcard mapping in IIS to handle all files. From the properties of the IIS website, choose "Home Directory" and click "Configuration". At the bottom of the next window is a "Wildcard application maps" box. Click insert and navigate to the version of .Net you use to find the aspnet_isapi.dll file. This will force all files to parse against this file (which is harmless except that it kicks up the authentication request).
I can't provide specific code samples because of NDA, but this should at least provide some ideas on where to go from here.
You can have classic ASP pages running inside an ASP.NET application. You can add your pages in ASP.NET
We have an old web app written in classic ASP. We don't have the resources to rewrite the app.
I know that asp and aspx pages can coexist in the same ASP.NET web app, but it appears as those you cannot share Application and probably Session variables across these two groups of page extension types.
I was hoping to do new development in ASP.NET and to in theory, convert the Classic ASP pages over as we go.
Is there a way to share IIS variables across these two types of web pages (aside from passing information using the query string and forms fields)?
There is no straigthforwad solution for sharing session variables between classic ASP and ASP.NET. I would recommend you to persist sessions into a database, like it is described in this Microsoft Article. This way both ASP and ASP.NET can access session variables.
Not a direct way. You could consider using a shared database backend for your session state.
You could create a simple table in your DB to store the "session" info in. Both the classic asp and the .net pages could read and write there.
The only ways to pass this data would be GET/POST values, cookies, flat file, or storing the data to the database. There is nothing "Built In" to the .Net framework to do this.
I have seen another solution aside from using the database as shared session holder. I should say beforehand that using the database option is probably much better than this. But...
You can create an ASP page whose only function is to store into and retrieve from the ASP session state. From your ASPX page you can make a webrequest to your ASP page and return any session information in the header, querystring, or even do a scrape of the restulant load. Alternatively you can return an XML stream and make a poor man's web service.
I addition, you could get session state from ASP.NET by doing the opposite and making a .NET page that access session info and returns it.
It's not a good idea and fraught with security problems. I have seen it done is all I'm saying. It's really probably best to rely on the database and possibly pass session ID around.
Well I just have faced this problem, and want to tell you that just were able to solve it in one way. The solution was relatively easy and actually depends on your original development, in my case the system flow requires to log-in in a default.aspx page and after validating the user/password are correct the page Init.asp is executed and exactly there many session vars are created and loaded (actually are just the minimum needed) after that the last instruction redirects the user to mainmenu.aspx and form that page we call .aspx and .asp files.
This solution worked for me just because of the election the original developer made when designed this ASP 3.0 application and as you can imagine I can't retrieve those values in the asp.net pages.
I just went through this. My solution was to wrap it all in a nodejs app. I dole out JWT tokens from .NET web API that have all the users claims encoded in the payload. This token gets stored in a cookie on the client. The cookie will automatically get submitted on each request to your domain so all you need to do is read the cookie value from the header and decode the payload (in ASP.NET and Classic ASP independently). Once you read the contents, you can simply set the session variables to match those that were embedded in the JWT token.
I prefer this method because it has 0 database synchronization necessary and moves your application to OAuth2 openid and away from session.
I am creating a standalone asp.net page that needs to be embedded into a sharepoint site using the Page Viewer Web Part. The asp.net page is published to the same server on a different port, giving me the URL to embed.
The requirement is that after a user is authenticated using Sharepoint authentication, they navigate to a page containing the asp.net web part for more options.
What I need to do from this asp.net page is query Sharepoint for the currently authenticated username, then display this on the page from the asp.net code.
This all works fine when I debug the application from VS, but when published and displayed though Sharepoint, I always get NULL as the user.
Any suggestions on the best way to get this to work would be much appreciated.
If you want to retrieve the currently authenticated user from the SharePoint context, you need to remain within the SharePoint context. This means hosting your custom web application within SharePoint (see http://msdn.microsoft.com/en-us/library/cc297200.aspx). Then from your custom application reference Microsoft.SharePoint and use the SPContext object to retrieve the user name. For example:
SPContext.Current.Web.CurrentUser.LoginName
You can still use the Page Viewer Web Part to reference the URL of the site, now located within the SharePoint context.
Thanks heaps for the answers!
Turns out that as long as the asp.net page is using the same URL and port as the Sharepoint site, authentication works across both sites.
The solution is to use a Virtual Directory inside of the sharepoint site and install the asp.net page there.
When it works in debug, is that being used in SharePoint?
Your page and the Sharepoint site might as well be on different servers as far as authentication is concerned -- in order to get the information over you might need to pass it via the QueryString from the webpart if you can -- or you might need to make your own webpart to do this (just put an IFRAME in the part with the src set to your page with the QueryString passing the username).
It does seem that this would be a security issue if you use the name for anything though -- if you are just displaying it, then it's probably fine.
If you actually need to be authenticated, you might need to add authentication into the web.config of the site hosting your standalone page.
edit: I think you'd have better luck putting your page on the same port and server as SharePoint.
I suspect you will have a hard time specifically querying SharePoint for the currently authenticated username. I can't think of a way to easily access the SharePoint context from a separate web application like you are describing.
I don't know what kind of authentication scheme you are using, but you may want to consider using Kerberos, as I've found that it can make these kinds of scenarios a little easier by allowing for delegation and passing credentials from application to application or server to server.