Develop Reference

How much can I trust ASP.NET Request Validation with Web Pages/WebMatrix vs. XSS?

I have read (and am coming to terms with) the fact that no solution can be 100% effective against XSS attacks. It seems that the best we can hope for is to stop "most" XSS attack avenues, and probably have good recovery and/or legal plans afterwords. Lately, I've been struggling to find a good frame of reference for what should and shouldn't be an acceptable risk.
After having read this article, by Mike Brind (A very good article, btw):
http://www.mikesdotnetting.com/Article/159/WebMatrix-Protecting-Your-Web-Pages-Site
I can see that using an html sanitizer can also be very effective in lowering the avenues of XSS attacks if you need the user-input unvalidated.
However, in my case, it's kind of the opposite. I have a (very limited) CMS with a web interface. The user input (after being URL encoded) is saved to a JSON file, which is then picked up (decoded) on the view-able page. My main way for stopping XSS attacks here is that you would have to be one of few registered members in order to change content at all. By logging registered users, IP addresses, and timestamps, I feel that this threat is mostly mitigated, however, I would like to use a try/catch statement that would catch the YSOD produced by asp.net's default request validator in addition to the previously mentioned methods.
My question is: How much can I trust this validator? I know it will detect tags (this partial CMS is NOT set up to accept any tags, logistically speaking, so I am fine with an error being thrown if ANY tag is detected). But what else (if anything) does this inborn validator detect?
I know that XSS can be implemented without ever having touched an angle bracket (or a full tag, at all, for that matter), as html sources can be saved, edited, and subsequently ran from the client computer after having simply added an extra "onload='BS XSS ATTACK'" to some random tag.
Just curious how much this validator can be trusted if a person does want to use it as part of their anti-XSS plans (obviously with a try/catch, so the users don't see the YSOD). Is this validator pretty decent but not perfect, or is this just a "best guess" that anyone with enough knowledge to know XSS, at all, would have enough knowledge that this validation wouldn't really matter?
-----------------------EDIT-------------------------------
At this site...: http://msdn.microsoft.com/en-us/library/hh882339(v=vs.100).aspx
...I found this example for web-pages.
var userComment = Request.Form["userInput"]; // Validated, throws error if input includes markup
Request.Unvalidated("userInput"); // Validation bypassed
Request.Unvalidated().Form["userInput"]; // Validation bypassed
Request.QueryString["userPreference"]; // Validated
Request.Unvalidated().QueryString["userPreference"]; // Validation bypassed;
Per the comment: "//Validated, throws error if input includes markup" I take it that the validator throws an error if the string contains anything that is considered markup. Now the question (for me) really becomes: What is considered markup? Through testing I have found that a single angle bracket won't throw an error, but if anything (that I have tested so far) comes after that angle bracket, such as
"<l"
it seems to error. I am sure it does more checking than that, however, and I would love to see what does and does not qualify as markup in the eyes of the request validator.

I believe the ASP.NET request validation is fairly trustworthy but you should not rely on it alone. For some projects I leave it enabled to provide an added layer of security. In general it is preferable to use a widely tested/utilized solution than to craft one yourself. If the "YSOD" (or custom error page) becomes an issue with my clients, I usually just disable the .NET request validation feature for the page.
Once doing so, I carefully ensure that my input is sanitized but more importantly that my output is encoded. So anywhere where I push user-entered (or web service, etc. -- anything that comes from a third party) content to the user it gets wrapped in Server.HtmlEncode(). This approach has worked pretty well for a number of years now.
The link you provided to Microsoft's documentation is quite good. To answer your question about what is considered markup (or what should be considered markup) get on your hacker hat and check out the OWASP XSS Evasion Cheat Sheet.
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#HTML_entities

Exploitable C# Functions [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
This question is similar to Exploitable PHP Functions.
Tainted data comes from the user, or more specifically an attacker. When a tainted variable reaches a sink function, then you have a vulnerability. For instance a function that executes a sql query is a sink, and GET/POST variables are sources of taint.
What are all of the sink functions in C#? I am looking for functions that introduce a vulnerability or software weakness. I am particularly interested in Remote Code Execution vulnerabilities. Are there whole classes/libraries that contain nasty functionally that a hacker would like to influence? How do people accidentally make dangerous C# code?

Anything that uses regular expressions (particularly the RegularExpressionValidator). To see this, run a RegularExpressionValidator with the regex ^(\d+)+$ and give it 30 digits and an alpha character to validate against.
Some posts:
http://msdn.microsoft.com/en-us/magazine/ff646973.aspx
This is called a Regular Expression Denial of Service attack and it can bring a website to its knees.

On the web based side of things, C# (and more generally, ASP.NET) is commonly vulnerable to the following (items listed by OWASP Top 10 2013). I realise you were mainly interested in sink functions, of which I cover some, however you did ask how people accidentally make dangerous C# code so hopefully I've provided some insight here.
A1-Injection
SQL Injection
Generating queries by string concatenation.
var sql = "SELECT * FROM UserAccount WHERE Username = '" + username "'";
SqlCommand command = new SqlCommand(sql , connection);
SqlDataReader reader = command.ExecuteReader();
This can often be solved by parameterised queries, but if you are using an IN condition it currently isn't possible without string concatenation.
LDAP Injection
Code such as
searcher.Filter = string.Format("(sAMAccountName={1})", loginName);
can make the application vulnerable. More information here.
OS Command Injection
This code is vulnerable to command injection because the second parameter to Process.Start can have extra commands passed to it using the & character to batch multiple commands
string strCmdText= #"/C dir c:\files\" + Request.QueryString["dir"];
ProcessStartInfo info = new ProcessStartInfo("CMD.exe", strCmdText);
Process.Start(info);
e.g. foldername && ipconfig
A2-Broken Authentication and Session Management
Sign Out
The default Forms Authentication SignOut method does not update anything server side, allowing a captured auth token to be continued to be used.
Calling the SignOut method only removes the forms authentication cookie. The Web server does not store valid and expired authentication tickets for later comparison. This makes your site vulnerable to a replay attack if a malicious user obtains a valid forms authentication cookie.
Using Session State for Authentication
A session fixation vulnerability could be present if a user has used session state for authentication.
A3-Cross-Site Scripting (XSS)
Response.Write (and the shortcut <%= =>) are vulnerable by default, unless the developer has remembered to HTML encode the output. The more recent shortcut <%: HTML encodes by default, although some developers may use this to insert values into JavaScript where they can still be escaped by an attacker. Even using the modern Razor engine it is difficult to get this right:
var name = '#Html.Raw(HttpUtility.JavaScriptStringEncode(Model.Name))';
ASP.NET by default enables Request Validation, which will block any input from cookies, the query string and from POST data that could potentially be malicious (e.g. HTML tags). This appears to cope well with input coming through the particular app, but if there is content in the database that is inserted from other sources like from an app written using other technologies, then it is possible that malicious script code could still be output. Another weakness is where data is inserted within an attribute value. e.g.
<%
alt = Request.QueryString["alt"];
%>
<img src="http://example.com/foo.jpg" alt="<%=alt %>" />
This can be exploited without triggering Request Validation:
If alt is
" onload="alert('xss')
then this renders
<img src="http://example.com/foo.jpg" alt="" onload="alert('xss')" />
In old versions of .NET it was a bit of a mine-field for a developer to ensure that their output was correctly encoded using some of the default web controls.
Unfortunately, the data-binding syntax doesn’t yet contain a built-in encoding syntax; it’s coming in the next version of ASP.NET
e.g. not vulnerable:
<asp:Repeater ID="Repeater1" runat="server">
<ItemTemplate>
<asp:TextBox ID="txtYourField" Text='<%# Bind("YourField") %>'
runat="server"></asp:TextBox>
</ItemTemplate>
</asp:Repeater>
vulnerable:
<asp:Repeater ID="Repeater2" runat="server">
<ItemTemplate>
<%# Eval("YourField") %>
</ItemTemplate>
</asp:Repeater>
A4-Insecure Direct Object References
MVC model binding can allow parameters added to POST data to be mapped onto the a data model. This can happen unintentionally as the developer hasn't realised that a malicious user may amend parameters in this way. The Bind attribute can be used to prevent this.
A5-Security Misconfiguration
There are many configuration options that can weaken the security of an application. For example setting customErrors to On or enabling trace.
Scanners such as ASafaWeb can check for this common misconfigurations.
A6-Sensitive Data Exposure
Default Hashing
The default password hashing methods in ASP.NET are sometimes not the best.
HashPasswordForStoringInConfigFile() - this could also be bad if it is used to hash a plain password with no added salt.
Article "Our password hashing has no clothes" regarding the ASP.NET membership provider in .NET 4.
A7-Missing Function Level Access Control
Failure to Restrict URL Access
In integrated pipeline mode .NET can see every request and handles can authorise each request, even to non .NET resources (e.g. .js and images). However, if the application i running in classic mode, .NET only sees requests to files such as .aspx so other files may be accidentally unsecured. See this answer for more detail on the differences.
e.g. www.example.com/images/private_photograph_user1.jpg is more likely to be vulnerable in an application that runs in classic mode, although there are workarounds.
A8-Cross-Site Request Forgery (CSRF)
Although the legacy web forms applications are usually more secure against CSRF due to requiring the attacker to forge the View State and Event Validation values, newer MVC applications could be vulnerable unless the developer has manually implemented anti forgery tokens. Note I am not saying that web forms is not vulnerable, just that it is more difficult that simply passing on a few basic parameters - there are fixes though, such as integrating the user key into the View State value.
When the EnableEventValidation property is set to true, ASP.NET validates that a control event originated from the user interface that was rendered by that control. A control registers its events during rendering and then validates the events during postback or callback handling. For example, if a list control includes options numbered 1, 2, or 3 when the page is rendered, and if a postback request is received specifying option number 4, ASP.NET raises an exception. All event-driven controls in ASP.NET use this feature by default.
[EnableEventValidation] feature reduces the risk of unauthorized or malicious postback requests and callbacks. It is strongly recommended that you do not disable event validation.
A10-Unvalidated - Redirects and Forwards
Adding code such as
Response.Redirect(Request.QueryString["Url"]);
will make your site vulnerable. The attack could be initiated by sending a phishing email to a user containing a link. If the user is vigilant they may have double checked the domain of the URL before clicking. However, as the domain will match your domain which the user trusts, they will click the link unaware that the page will redirect the user to the attacker's domain.
Validation should take place on Url to ensure that it is either a relative, allowed URL or an absolute URL to one of your own allowed domains and pages. You may want to check someone isn't redirecting your users to /Logout.aspx for example. Although there may be nothing stopping an attacker from directly linking to http://www.example.com/Logout.aspx, they could use the redirect to hide the URL so it is harder for a user to understand which page is being accessed (http://www.example.com/Redirect.aspx?Url=%2f%4c%6f%67%6f%75%74%2e%61%73%70%78).
Others
The other OWASP categories are:
A9-Using Components with Known Vulnerabilities
of which I can't think of any to mind that are specific to C#/ASP.NET. I'll update my answer if I think of any (if you think they are relevant to your question).

Process.Start is the first one to come to mind.
I am sure that WindowsIdentity and much of System.Security can also be used for evil.
Of course, there are SQL injection attacks, but I don't think that's what you mean (though remote execution can occur through SQL Server).

Aside from the obvious Process.Start() already mentioned, I can see a couple of ways of potential indirect exploitation.
WinAPI calls via PInvoke to CreateProcess() and whatnot.
Any sort of dynamic assembly loading mechanism using Assembly.Load() and other such overloads. If a compromised assembly made it to the system and loaded.
If running in full trust in general.
With the right permissions, any registry operations could put you at risk.
That's all that comes to mind right now.

IMO: The nr 1 exploitable functions, are innocent looking, but very dangerously when used without thought.
In ASP.Net Response.Write or the shortcut:
<%= searchTermFromUser %>
In ADO.Net:
The string + operator:
var sql = "SELECT * FROM table WHERE name = '" + searchTermFromUser + "'"

Any piece of data you get from the user (or any other external source) and pass to another system or another user is a potential exploit.
If you get a string from the user and display it to another user without using HtmlEncode it's a potential exploit.
If you get a string from the user and use it to construct SQL it's a potential SQL injection.
If you get a string from the user and use it to contract a file name for Process.Start or Assembly.Load it's a remote execution vulnerability
You get the point, the danger comes from using unsanitized data, if you never pass user input to external system without sanitizing it (example: HtmlEncode) or using injection-safe interfaces (example: SQL parameters) you are relatively safe - the minute you forget to sanitize something the most innocent-looking method can become a security vulnerability.
Note: cookies, html headers and anything else that passes over a network is also data from the user, in most cases even data in your database is data from the user.

Plenty of things in the System.Net, System.XML, System.IO, (anything that takes a URI and/or file path and actually deals with the resource they identify) System.Reflection, System.Security, System.Web, System.Data and System.Threading namespaces can be dangerous, as in they can be used to do bad things that go further than just messing up the current execution. So much that it would be time consuming to try to identify each.
Of course, every method in all third party assemblies will have to assumed to be dangerous until shown otherwise. More time consuming again.
Nor do I think it's a particularly fruitful approach. Producing a checklist of functions only really works with a limited library, or with a large-language where a lot of what would be in a library with a language like C# is in the language itself.
There are some classically dangerous examples like Process.Start() or anything that executes another process directly, but they are balanced by being quite obviously dangerous. Even a relatively foolhardy and incompetent coder may take care when they use that, while leaving data that goes to other methods unsanitised.
That sanitation of data is a more fruitful thing to look at than any list of functions. Is data validated to remove obviously incorrect input (which may be due to an attack, or may simply be a mistake) and is it encoded and escaped in the appropriate way for a given layer (there is too much talk about "dangerous" character sequences, ' never hurt anyone, it's ' not correctly escaped for SQL, that can hurt when it is indeed at a SQL layer - the job required to make sure the data gets in there correctly is the same as that to avoid exploits). Are the layers at which communication with something outside of the code solid. Are URIs constructed using unexamined input, for example - if not you can turn some of the more commonly used System.Net and System.XML methods into holes.

Using any type of unsafe code can cause problems such as pointers. Microsoft provided a good article about unsafe code here: http://msdn.microsoft.com/en-us/library/aa288474(VS.71).aspx

Reflection.Emit and CodeDom
Edit:
Allowing plugins or third party libraries that uses threading can bring your whole application down unless you load those libraries/plugins in a separate appdomain.

Probably half the framework contains very scary functions. I myself think that File.WriteAllText() is very scary since it can overwrite any file the current user has access to.
A different approach to this question would be how you can manage security. The article at http://ondotnet.com/pub/a/dotnet/2003/02/18/permissions.html contains a basic description concerning the .NET security system, with the System.Security.Permissions namespace containing all permissions .NET makes available. You can also take a look at http://msdn.microsoft.com/en-us/library/5ba4k1c5.aspx for more information.
In short, .NET allows you to limit the permissions a process can have, for example denying methods that change data on disk. You can then check these permissions and act on whether the process has them or not.

even a simple string comparison can be an issue.
If an application makes a trust
decision based on the results of this
String.Compare operation, the result
of that decision could be subverted by
changing the CurrentCulture
Take a look at the example. Fairly easy to miss

I've seen code where the user could set the name and parameters for a function call in a database. The system would then execute the named function through Reflection without checking anything ...

Why isn't ValidateRequest="true" enough for XSS prevention?

In the notes for Step 1 in the "How To: Prevent Cross-Site Scripting in ASP.NET" it is stated that you should "not rely on ASP.NET request validation. Treat it as an extra precautionary measure in addition to your own input validation."
Why isn't it enough?

For one thing, hackers are always coming up with new attacks and new ways of inserting XSS. ASP.NET's RequestValidation only gets updated when a new version of ASP.NET gets released, so if someone comes up with a new attack the day after an ASP.NET release RequestValidation won't catch it.
That (I believe) is one of the reasons why the AntiXSS project appeared, so it can have a faster release cycle.

Just two hints:
Your application might output not only data that was entered using your ASP.NET forms. Think of web services, RSS feeds, other databases, informations extracted from user uploads etc.
Sometimes it's necessary to disable the default (effective but overly simple) request validation because you need to accept angle brackets in your forms. Think of a WYSIWYG editor.

Options for storing Session state with SharePoint

I have written a user control for our SharePoint site that builds an HTML menu - this has been injected into the master page and as such ends up rendering on all pages that use it. There are some pretty computationally expensive calls made while generating this HTML and caching is the logical choice for keeping the page loads snappy. The HttpRuntime Cache has worked perfectly for this so far.
Now we are embarking down version 1.1 of this user control and a new requirement has crept in to allow per-user customization of the menu. Not a problem, except that I can no longer blindly use the HttpRuntime Cache object - or at least, not use it without prefacing the user id and making it user specific someway.
Ideally I would like to be able to use the ASP.NET Session collection to store the user specific code. I certainly don't need it hanging around in the cache if the user isn't active and further, this really is kind of session specific data. I have looked at several options including it in the ViewState or enabling Session management (by default it is disabled for a good reason). But I am really not all that happy with either of them.
So my question is: How should I go about caching output like this on a per user basis? Right now, my best bet seems to be include their user id in the Cache key, and give it a sliding expiration.

It's worth pointing out that I believe the 'end of days' link providing is relevant for SPS2003 not MOSS2007 - afaik MOSS integration into Asp.Net means that the mentioned issue is not a problem in MOSS.

I use ViewState on a fairly large MOSS 2007 deployment (1000+ users) for custom webparts and pages, and I haven't noticed a detrimental effect on the deployment performance at all.
Just use it, is my advice.

I don't understand why you wouldn't use SharePoints built in web part caching mechanism for this on a per user basis (Personal) - its exactly what its designed for.
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.webpartpages.webpart.partcacheread.aspx

ASP.NET - Common Gotchas [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
When I am working with ASP.NET, I find that there are always unexpected things I run into that take forever to debug. I figure that having a consolidated list of these would be great for those "weird error" circumstances, plus to expand our knowledge of oddness in the platform.
So: answer with one of your "Gotcha"s!
I'll start:
Under ASP.NET (VB), performing a Response.Redirect inside a try/catch block does not stop execution of the current Response, which can lead to two concurrent Responses executing against the same Session.

Don't dynamically add controls after the page init event as it will screw up the viewstate tree.

Viewstate ... if you are using it ... can get out of control if you are not paying attention to it.

The whole life-cycle thing in general.
Not that I see anything wrong with it, it's just that you'd be amazed at the number of people who start working on large ASP.Net projects before understanding it, rather than vice versa. Hence, it becomes a gotcha.
Note that I said large projects: I think the best way to come to terms with the life cycle is to work on a few smaller projects yourself first, where it doesn't matter so much if you screw them up.

Life cycle of custom controls does not match up perfectly with page life cycle events of same name.

Page_Load is run before control handlers. So you can't make changes in an event handler and then use those changes in the page load. This becomes an issue when you have controls in a master page (such as a login control). You can get around the issue by redirecting, but it's definitely a gotcha.

Having to jump through hoops to get the .ClientID property into javascript.
It'd be nice if the render phase of the lifecycle created a script that set up a var for each server control with the same name as the control that was automatically initialized to the clientID value. Or maybe have some way to easily trigger this action.
Hmm... I bet I could set up a method for this on my own via reflection.

Don't edit your web.config with notepad if you have accented characters, it will replace it with one with the wrong encoding. It will look the same though. Just your application will not run.

I just learned this today: the Bind() method, as used with GridViews and ListViews, doesn't exist. It's actually hiding some Reflector magic that turns it into an Eval() and some kind of variable assignment.
The upshot of this is that calls like:
<%# FormatNameHelper(Bind("Name")) %>
that look perfectly valid will fail. See this blog post for more details.

Debugging is a very cool feature of ASP.Net, but as soon as you change some code in the app_code folder, you trigger a re-build of the application, leading to all sessions being lost.
This can get very annoying while debugging a website, but you can easily prevent this using the "StateServer mode" : it's just a service to start and a line to change in the web.config :
refer to msdn : http://msdn.microsoft.com/en-us/library/ms178586.aspx
InProc mode, which stores session state in memory on the Web server. This is the default.
StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
SQL Server ...
Custom ...
Off!

If you are running Classic ASP applications in the same Virtual Directory as you ASP.Net application, the fist hit on the application must be on an ASP.Net page. This will ensure that the AppPool be built with the right context configurations. If the first page to be hit is a Classic ASP page, the results may vary from application to application. In general the AppPool is configured to use the latest framework.

Making a repeater-like control, and not knowing about INamingContainer.

You have to worry about session timeouts for applications where the user might take a long time.
You also have to worry about uploading timeouts for large applications, too
Validatiors may not always scroll your page to the scene of the data entry error (so the user may not ever see it and will only wonder why the submit button won't work )
If the user enters HTML symbols such as <, > (for example, P > 3.14 ), or an inadvertant <br> from copy-pasting on another page, ASP.NET will reject the page and display a error.
null.ToString() produces a big fat error. Check carefully.
Session pool sharing across multiple applications is a disaster silently waiting to happen
Moving applications around on machines with different environments is a migraine that involves web.config and many potential hours of google
ASP.NET and MySQL are prone to caching problems if you use stored procedures
AJAX can make a mess, too:
There are situations where the client can bypass page validation (especially by pressing ENTER instead of pressing the submit button). You can fix it by calling if(! Page.IsValid) { return ; }
ASP buttons usually don't work correctly inside of UpdatePanels
The more content in your UpdatePanel, the more data is asynchronously transmitted, so the longer it takes to load
If your AJAX panel has a problem or error of some kind, it "locks up" and doesn't respond to events inside it anymore

Custom controls are only supported by the designer when building the control or when building the page that uses the control, but not both.

When using a gridview without a datasource control (i.e. binding a dataset straight to the control) you need to manually implement sorting and paging events as shown here:
http://ryanolshan.com/technology/gridview-without-datasourcecontrol-datasource/

Linq: If you are using Linq-To-SQL, you call SubmitChanges() on the data context and it throws an exception (e.g. duplicate key or other constraint violation), the offending object values remain in your memory while you are debugging, and will be resubmitted every time you subsequently call SubmitChanges().
Now here's the real kicker: the bad values will remain in memory even if you push the "stop" button in your IDE and restart! I don't understand why anyone thought this was a good idea - but that little ASP.NET icon that pops up in your system tray stays running, and it appears to save your object cache. If you want to flush your memory space, you have to right-click that icon and forcibly shut it down! GOTCHA!

You can't reference anything at all above the application's root folder.

All the code I have to maintain that still looks like it was written in vb6, showing complete ignorance of the newer styles.
I'm talking things like CreateObject(), excessive <% %> blocks, And/Or instead of AndAlso/OrElse, Len() instead of .Length(), s/o Hungarian prefix warts, Dim MyVariable with no type, functions with no return type... I could go on.

Being unaware of heaps of existing and extensible functionality in the framework. Things often redone are membership, roles, authorization, site maps. Then there are the controls and the associated tags which can be customized to alleviate issues with the client IDs among others. Also simple things like not knowing to properly use the .config file to auto import namespaces into templates, and being able to do that on a directory basis. Less known things like tag expressions can be valuable at times as well. Surely, as with all frameworks, there is a learning curve and always something left to be desired, however more often than not it is better to customize and extend an existing framework instead of rolling your own.

Not a pure ASP.NET thing, but ...
I was trying to use either a) nested SELECT or b) WITH clause and just could not get it to work, but people who were obviously more knowledgeable (including someone I work with) told me the syntax was fine. TURNS OUT ...
Was not able to use either of those with OLEDB.
OLEDB query to SQL Server fails
(Also, I was bit by the response.redirect() in the try ... catch 'feature' mentioned in the OP! Great thread!)

Databound controls inside an INamingContainer control must not be placed inside templated controls such as FormView. See this bug report for an example. Since INamingContainer controls creates their own namespace for their contained controls, two-way databinding using Bind() will not work properly. But when loading the values everything will look fine (because it is done with Eval()) it is not before you try to post back the values that they will mysteriously seem to not land in the database.
This so question demonstrates the issue well: AJAX Tabcontainer inside formview not inserting values

(VB.NET) If you send an Object via a Property's Get accessor into a function with a ByRef keyword, it will actually attempt to update the object using the Set accessor for the Property.
Ex:
UpdateName(ByRef aName as String)
UpdateName(Employee.Name) will attempt to update the name by using the Set on the Name property of Employee.