Related
I have a grammar where a language statement (outside of flow statements) is comprised of <expression>;. Currently, when ANTLR parses and finds the missing ;, it identifies it as missing at the position of the next token, which generally means the start of the next line. This is less than ideal, since in this case it is more correct to say it is missing at the end of the previous token, rather than the start of the next.
Is there a way to instruct ANTLR to indicate the end of the previous token as the position for the error, rather than the start of the next token? I understand why the parser sees it this way, but for a person, it can be a little confusing (especially for newbie programmers that might be learning the language). I'm using this in a GUI editor project to given programmers a better tool, so I would like to also deliver a better error message (since the goal is to deliver a better development and learning experience).
I am using a custom IAntlrErrorListener<IToken> implementation to collect the errors for display to the programmer, in case that is important. I'm hoping there is an easy way to perhaps indicate this at a parser rule level, such that the parser can easily be instructed to indicate end of the preceding token as the problem position, rather than the start of the next token.
When you create your listener, you could get a reference to the token stream. From the token the error is reported on you could get the use getTokenIndex() and then you can subtract 1 from that and use the get() method of the token stream to get the previous token.
Note: It probably won’t prove quite so simple as there may be multiple tokens and/or skipped tokens that you have to account for to get to the token you really want to use. So, while you can get to other tokens in the stream it might be “fiddly” to get to the previous token that you want for your error message. (And this is probably getting at why ANTLR gives you the reference that it does)
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
I am not a software engineer as you will see if you continue reading, however I managed to write a very valuable application that saves our company lots of money. I am not paid to write software, I was not paid for writing this application, nor is my job title software engineer so I would like to have total control over who uses this application if I ever had to leave since as far as I can tell it is not legally theirs (did not write during company hours either).
This may sound childish but I've put much much time into this and I've been maintaining it almost on a daily basis so I feel that I should have some control over it, or at least could sell it to my company if they ever had to let me go, or I wanted to move on.
My current protection scheme on this application looks something like this:
string version;
WebRequest request = WebRequest.Create("http://MyWebSiteURL/Licence text file that either says 'expired' or "not expired'");
WebResponse response = request.GetResponse();
StreamReader stream = new StreamReader(response.GetResponseStream());
version = stream.ReadToEnd();
stream.Close();
response.Close();
if (version == ("not expired") == false)
{
MessageBox.Show(Environment.NewLine + "application expired etc etc", "Version Control");
}
It checks my server for "not expired" (in plain text), and if the webrequest comes back as anything but "not expired", it ultimately pops up another form stating it is expired and allows you to type in a passcode for the day which is a multiplication of some predetermined numbers times the current date to create "day passes" if ever needed (I think Alan Turing just rolled over in his grave).
Not the best security scheme, but I thought it was pretty clever having no experience in software security. I have however heard of hex editing to get around security so I did a little test for science and found this area of my compiled EXE:
"System.Net.WebRequest." Which I filled in with zeros to look like this: System.Net000000000
That was all it took to offset the loading of the application to hiccup during the server check which allowed me to click "continue" and completely bypass all my "security" and go along using the program without it ever expiring.
Now would a normal person go to this length (hex editing) to try to get past my protection scheme? Not likely, however just as a learning experience, what could I do as an added step to make hex editing or any other common workarounds not work unless it was by "professional" cracker?
Again I'm not paranoid, I'm just eager to learn more about security of applications. I was both proud of myself and ashamed at the same time for creating and breaking my own protection.
If commenting, please be kind since I know this is probably a humerus post to those more informed than I as I really have little experience in writing software and have never taken any type of course etc. Thanks for reading!
Another way to bypass the license check is to redirect the checking url to localhost returning always the desired text...
A better way is to make a call to a function doing the same thing but make your server response a signed XML including the server response time-stamp, that you can check on addition with the system datetime (use UTC dates in both sides). It is also a good idea to throw exceptions whenever something is not the way you expect it, and control the flow of your program with exception handling.
Check the following to get a how to clue:
How to: Sign XML Documents with Digital Signatures
How to: Verify the Digital Signatures of XML Documents
Now would a normal person go to this length (hex editing) to try to
get past my protection scheme?
Well i guess, that depends on how useful the application is for that "normal person", and how determines he is to make it work.
Most .net application unless obfuscated can be easily de-compiled to the source code using tools like (Telerik JustDecompile) or they can simple use the ildasm to see the IL code, i heard there are tools to even de-compile obfuscated .net libraries, although i haven't used or found any.
With my little experience, i can suggest two approaches
Enforcing licensing and cracking it in a application which runs plainly on the user machine is a cat and mouse game, you can add some extra protection to your code by moving some part of the applications functionality to the server and expose it as a web service which your client can consume, the part you move to the server must be an important part for the application to work and should be something that is hard to simulate.
The other approach is to add a auto updater feature to your application that will check the server for latest updates, and when ever it finds a new version it will overwrite the older one, thus overriding any cracked version, this can be easily disabled, but if disabled this will also stop any bug fixes you might release
I tried both the approaches, but they are only useful to some extent and you have to decide whether it is worth the effort enforcing or not
In languages that support exception objects (Java, C#), when is it appropriate to use error codes? Is the use of error codes ever appropriate in typical enterprise applications?
Many well-known software systems employ error codes (and a corresponding error code reference). Some examples include operating systems (Windows), databases (Oracle, DB2), and middle-ware products (WebLogic, WebSphere). What benefits do error codes provide? What are the disadvantages to using error codes?
WITHIN a program one should always use exceptions instead of error codes. However, exceptions can't propagate beyond a program. Any time the error must leave the program you are left with error messages or error codes.
For simple things that will always be human-operated error messages without codes are fine. You can say "File not found" without giving it an error code. However, if it might be another computer on the other end then you should give error codes in addition. You don't want to break the other system when you change it to "File <x> not found".
I don't think I've ever used error codes in .Net except in one situation - when I was creating a console application that I knew was going to be called from another app. This other app had to know when the console app failed, and what went wrong. So, one example of when it would be appropriate would be when you know your program will be called by other programs, and you want a structured way for them to understand errors.
That said, I was a newbie to .NET at the time, and have never used error codes since.
As a side note, as a Windows guy, it's nice to be able to plop in an error code and come up with a KB article, so an error code combined with good documentation and the ability to find it = nice feelings from your users.
Very common for web service interfaces. It's very easy and standard to return a code with a description.
I agree that for most of the scenarios is old school
I'd say the biggest disadvantages it's the quality of code. You have to add more complex logic to manage error codes while exceptions are bubbled without having to use method parameters or return values.
You also have to add an "IF" to check if the returned code is SUCCESS or not, while exceptions goes directly to the error handling block.
I'm a newbie to stack overflow but...
I believe that error codes tend to be used or useful for dealing with erroneous situations that require an end-user of sorts to get involved to rectify a situation. If your code is to be maintained by another developer then exceptions is the way to go. However, in a situation where there is a problem:
in the environment that your application is running
with communication between your app and some other entity (web server, database, socket, etc)
that a device or device driver indicates (hardware failure maybe?)
then error codes may make sense. For example, if your app attempted to log into a database on behalf of your end-user, but the DB was unreachable for authentication (DB is off-line, cable is unplugged) then an error code/description combo might help the end-user rectify the problem.
Again at the developer/engineer level who will be able to touch the source code (traditional debugging and testing techniques) and modify it, use exceptions.
Hope this helps...
--jqpdev
I frequently use error codes when an error needs to be conveyed to the user, since they can be internationalized. For example, in a compiler, if there are errors in user code, errors can be signaled in the compiler backend, while the frontend can localize them into culture/language-specific strings for user consumption. Enums may be better for this purpose than raw integers, however.
I've also used them in creating an "error reporting" framework for the app. When exceptions were thrown, they were thrown with an error code, which, when the exception bubbled up, was sent (with a log) to the central server. The code helped organize the database so we could inspect logs related to a specific error.
Finally, as mentioned in a couple other answers, error codes are easy and language-agnostic to google (think Windows error codes/MS KB articles), so an error code with a description of what went wrong may be better for end-users of a technical product.
The idea of error codes is useful, but IMO they belong as exception members or as parameters to an IErrorReporter interface or something more ofthen than as method return values.
Error codes are old-school. They are of little to no value at all.
The only possible value to an error code is that it can identify a very specific circumstance. You could have a code for each point in the code base that can throw an exception. This would allow you to narrow down very precisely what the problem must be.
But nobody cares about that level of detail. Who wants to maintain such a mess. It would leave you with codes that meant something like "condition A and B but not C due to state S". It's more effort than it's worth to try to work out exactly what that means. A stack trace will be more valuable in telling you where in the program the problem occurred.
I learned to program computers before exceptions were a widespread technique. I'm so glad we got exceptions instead!
C#, and probably Java too, supports a better exception handling control flow, the finally keyword, which makes things a little nicer than using error codes. An exception object can contain any level of detail, certainly much more than an error code. So the exception object is way more practical, but you might run into an uncommon case where an error code would be more appropriate.
FWIW, C++ also supports exception objects. I don't think that C++ supports a finally keyword (though the newer C++ whatevers just might), but in C++ you also have to avoid things like returning inside a catch handler.
Error codes were designed in an age where the only way for a function to tell the caller that something went wrong was to assign a special meaning to one or more values of those which can be returned, and very frequently only a native integer or so was available for returning that special value.
For instance, in C the "get character" routine returns the next character value in ASCII, but returns a negative value if for some reason something went wrong. You are then responsible for returning to YOUR caller in a way so this error situation can be handled, and that must return etc.
The Exception mechanism is an elegant way to handle this "this is an emergency, we must return from code until something can deal with the problem". Error codes are inferior to this.
I've written many web services that are consumed by other (remote) applications. When things go badly with a request, customers more or less insist on getting a code, so that they don't have to do some horrific string comparison to find out what went wrong.
Take HTTP result codes as a fine example of this sort of behavior. "200" means happy, "300" could go either way, "400" or "500" means start freaking out.
Error codes are for if you want to send them to the user. If not, use an exception.
Sometimes you don't want to give too much information to the user when an error occurs. For example, a user is not able to sign a new contract. The error message only states something generic like "Cannot sign a new contract".
This adds difficulty to support cases where the user thinks this is not correct. If you have an error code, for example a number or an acronym, it could be part of the error message. The user wouldn't know what it means but the support staff could look it up and could then check if that specific reason for declining the new contract is indeed an error or not.
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.
At the company I work for, I have created a Error Logging class to handle errors in my ASP.net application. It is a custom class because we are not allowed to install additional software on our servers (nLog, log4net, etc).
I currently use it in two of my projects and have seen some good results from it. Right now I am trapping the errors that cause page and application errors. It sends and stores the error message and all inner exceptions.
The problem I am having now is, I am receiving errors that I am not quite sure how to reproduce. I have not heard any error reports from any of my users. I am not sure what they are doing, or even if they are seeing these as errors.
I am thinking about creating an Event Log on each page, or the ones I want additional information on. Keeping it as a Session variable on the page, and writing events to it (start/end of functions, variable changes, etc). Then only if an error is called to have that send along with the error message to see if it gives a better picture of what is going on. I am hoping that doing it this way will not give me tons of event logs when all users access the application, just want was going on right before the error happen with the one user.
Do you know of any pitfalls I should watchout with method?
Do you have any advise for things to look for?
Update:
#Saret: I understnad where you are coming from with that response and I agree. I am fairly new to this company and still need to learn how they do things. In the past I have had conversations with my coworkers how it would be great to have this product, or use this open source project. The problem comes down to is, we work on secure systems and getting approval to get these things takes a lot of time, top cover, and dealing with all the red tape. I will look into the situation further because I believe having a good error logging system in place is important, currently nothing is being used.
#Jim Blizard: I wanted to try to get away from logging/storing everything someplace to come back and find out what is important to the situation that caused the error. I didn't want to fall into overload of information that is talked about in artical that Roberto Barros linked. My current method of thinking is, keeping a string in memory on each page, and if an error is rasied, on the pages Page_Error event, grab that string and attach it to the exception that is getting logged. That way I am only logging the error/exceptions that occured and storing the event log with that error. If nothing happens, that log that was being created is dropped into the bit bucket never to be seen again.
#Roberto Barros: Thanks for that link, I remember reading it somewhere but forgot to save it.
This might not be the exact answer you are looking for, but why develop your own error logging mechanism when there are powerful tools (which you mention) that handle all these key issues for you?
I can appreciate you are not allowed to install additional software but aren't logging libraries just classes like your custom code? Where is the fundamental difference? I would reckon the time spent worrying about implementing a logging framework might be better spent advocating and making a business case for a decent logging solution.
I once worked for an agency that would not allow installation of anything that wasn't purely my own code or their (horrid) COM objects. If you have this type of limitation, then see if you can grab the source for log4net and include in your project.
There is nothing better than log4net currently when it comes to logging.
I personally took the following approach on logging erros (and only log errors) in an asp.net application:
use
protected void Application_Error(object sender, EventArgs e)
{
Server.Transfer("~/Support/ServerErrorSupport.aspx", true);
}
(I do a Server.Transfer to preserve all post data.)
Generate an error ID which is unique for this error (so subsequent repports for the same error can be grouped). The ID is an hash calculated from a concatenated string consisting of: file, method, lineNr and error.Message. I get the file, method and lineNr values through a regex on the stacktrace.
I log all the following data to an xml structure (depending on the data type, I store the value differently, value types => ToString(), ISerializable => serialize, ...):
MachineName: Application.Server.MachineName
PhysicalRoot: Application.Server.MapPath("~/")
RequestUrl: Application.Request.Url.ToString()
ApplicationSettings: WebConfigurationManager.AppSettings
ConnectionSettings: WebConfigurationManager.ConnectionStrings
QueryString: Application.Request.QueryString
FormPost: Application.Request.Form
Session: Application.Session
HttpHeaders: Application.Request.Headers
Save the xml structure as a local file containing the error ID and a timestamp.
I chose this approach because:
I can mail the rapport (xml-file) to myself (during test/debugging very easy)
store it locally or in a database during production
because the file is just a (dump to hd) save not much can go wrong during the creation of the error report (like a server connection, db problems, etc), just make sure you have write permissions.
Additionally on the servererrorsupport.aspx page, after saving the xml file, the user gets the option to include extra information and to add an emailaddress to keep updated on progress regarding the bug. This gets appended to the xml document.
I use an xslt file to format the error data (xml) in a nice error report.
For errors, I'm a big fan of logging A LOT. When things go wrong information is very valuable. I would keep the entire log in one place (text file or database table) with a session identifier to group relevant events together.
Here's what I like to log:
error/debug level (info, debug, problem, crash, etc...)
time
descriptive text (usually one line)
stack trace (if possible)
data (user, session, variable values, etc...)
The simplest way is to write to a text file, but it can be nice to have it in a database. You can also use the Windows event log. Some things to watch out for. Hmm... You'll need to clear out your logs periodically.
Funny story: one time we had an error logger that logged to the database, but we had bad database credentials which caused an error which was then logged... Ended up getting stack overflows from the recursion (IIRC).