Looking for Real Stories of Web Service Security Breaches [closed] - 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 8 years ago.
Improve this question
I'm a full time software developer, but on the side I'm teaching a university course on web services. I'm going over security right now and was wondering if any of you all have had any security breaches that you could tell about (details obscured as needed) that I could share with my students. Real life stories are a lot more meaningful than made up scenarios...

Here is a story from me:
I once was customer of an online audiobook store. Beside authenticating myself with username and password, I also needed my browser to accept cookies. This wasn’t unusual. The cookie is probably needed for storing the session ID.
But I got confused since the session ID was also transmitted in the URL and I didn’t saw a reason for why there was a need for cookies. So I took a look into my cookie jar to see what oh so important information have to be stored in cookies.
Beside a cookie for the session ID there was another cookie named customer_id that obviously was designated to identify me by my customer number. I thought: “Come on, no one can be this stupid!” I altered the value for fun by changing one digit of the number (e.g. from 12345 to 12346) to see what happens.
Now guess what: I now was logged in as a different user without any further request for authentication just by changing the cookie! The customer_id cookie value was abviously not just for identification (Who am I?) but also for authentication (Am I really the one who I pretend to be?)!
The moral of this story: Always separate identification from authentication.

This may not be what you had in mind, as there was no information compromised, but it still very much a web security issue.
http://www.crime-research.org/library/grcdos.pdf
That is the classic story of how internet security guru, Steve Gibson's, site was attacked by a botnet. It is a very interesting story and would certainly keep the class engaged. I know this story got me more interested in web security.
I could not find the original post of that pdf on Steve Gibson's site (grc.com), but I had a copy on my computer and was able to search for it and found it at the given location.
I also recommend going to grc.com and listening to the "Security Now!" podcasts:
http://www.grc.com/securitynow.htm
You will almost surely hear some stories in some of those podcasts.
Hope this helps!

The European Identity Conference (EIC 2009) in Munich will be featuring a case study on SOA security that will have the information you seek.

Related

What implications are involved in password change over the phone? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
An application I maintain offers a standard password reset script. My employer wants to add a tool for our support reps to set the password manually to something they pick themselves, and give the password to the customer over the phone.
Security in my application is expected to be top notch, so this sets all sorts of warning bells in my head.
Aside from the obvious no-no of allowing support staff to know customer passwords, What other security implications should I be aware of in this scenario? In the case of fraud, would this increase our legal liability?
My take on this is that you have to offer customers the ability to reset their password. Customers will forget their passwords and need them reset. Meeting the customer in person and confirming their identity is presumed to be out of the question, so it might as well be done over the phone after a human has verified the customer's identity (in some way that's deemed sufficient). Any written form of communication such as email is almost guaranteed to be archived somewhere, so having the password in that form is a bad idea. A phone conversation might be recorded too, but at least it's not searchable. YMMV.
That being said, the thing that you give out over the phone should most certainly be a temporary password that needs to be changed the first time the customer logs in with it (and preferably is only good for a short amount of time). Otherwise your staff will know the customer's password!
I can't speak to legal liability.
Since transmitting a strong random password through phone without errors is hard, support staff might gravitate towards choosing weak passwords (such as a dictionary word plus some letters) if they get the chance to do so. Also, they might write passwords down in case the customer misheard and calls back, which might result in even more people knowing the password.

Do form submissions by spam bots ever pose a security risk? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
A spam bot has found my sign-up form and is filling my database with spam submissions. The form is a basic asp.net registration that creates a new membership user and captures account information such as name, address, phone, etc. Rather than implement a captcha I plan to try a honeypot field. However, my question is not about prevention* but rather about security. What potential risk does form spam pose? I already parameterize all of my SQL to handle the obvious SQL injection stuff. What are the other risks? Is anyone aware of how one might use a bot to attack a site through the site's form(s)? When do spam submissions represent more than just spam?
**Here are some posts related to prevention for anyone who is interested:*
fighting spam bots
How to deal with botnets and automated submissions
When the bots attack!
Any security risks you may have are completely independent of whether the form is being submitted in bulk.
The only new security risk relates to what happens if the bots fill up your disk.
I guess one problem could be the kind of spam they post. If they post links to other websites which in turn try infect the visitor with malware it doesn't pose a direct threat to your site but to your visitors.
You should also make sure they can't insert scripts etc to prevent XSS.
XSS on wikipedia
From a security perspective, this is really a question about how secure your website is in general. Yes, a spambot could exploit vulnerabilities but then so could any user, be they human or robot.
You mentioned parametrisation of SQL which is a good start, try these as well:
Are you validating all input against a whitelist of trusted values?
Are you applying the principle of least privilege and not allowing the SQL account public users connect with to do more than it needs? (more on that here)
Are you output encoding every piece of data when it's presented back via the UI?
If you're doing all this then you're in good shape security wise. Dealing with the inconvenience created by bots is another issue altogether.

How does Yodlee work? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
From what I understand, you have to enter in all of your usernames and passwords into Mint, so I assume they are actually logging into your bank account and scraping the resulting screen to put this data into a form that Mint and others use.
How do they actually simulate the keypresses and mouse clicks? I assume banks don't like it when they do this - how do their scrapers avoid detection?
I'm pretty sure they don't simulate clicks, etc. In the end, any data that ends up on a user's page is transmitted in a response to a request. If you can figure out how to construct a valid request and then how to parse the response, you'll have the data you want.
As far as I could gather after using Yodlee for quite a while, they deal with sites in two major ways: the sites they have official agreements to work with and the sites they don't have official agreements with. For the first category of sites they, most often, have agreed upon APIs for getting the data. For the sites in the second category they reverse-engineer layer 7 communication protocols and data structures (a.k.a. screen/html scraping).
The way I understand it, Yodlee uses the OFX specification to access banks' financial information.
http://www.ofx.net/
For the banks that don't implement OFX, they use custom screen scrapers, which must constantly be updated when banks change the information that's displayed on their site.
I don't know Yodlee so i simply assume it's like "sofortüberweisung.de" where you give a 3rd party your bank login data (and depending on what you do even a valid TAN) and thus trust them not to abuse it and additionally break your bank's security regulations ("NEVER GIVE YOUR YOUR PIN/TAN").
They most likely simulate what a browser would do. As web-based banking interfaces are usually just HTML/JavaScript everyone can look at the client-side code and do whatever it does with a custom program. Since those actions are not done in a malicious way, actions which require e.g. a TAN or a CAPTCHA to be solved can be simply forwarded to the legit user who will then enter the necessary TAN or solve the CAPTCHA.
Nonetheless to say, it is really bad to use services like that. While they most likely won't do anything bad you cannot know it for sure. And your bank is damn right if they don't refund you anything if you ever get scammed by such a service.
Another solution which would be perfectly safe (as long as you are not concerned about a 3rd party knowing about your financial status etc.) would be the yodlee company making contracts with major banks allowing them to access your data after you've authorized it through some way (you can already do that on pages like Twitter - I'd never do that for bankign though but technically it wouldn't be hard to realize something like that). That would be clean and secure as it would not involve "screen-scraping" or customers entering their banking login data anywhere but on their bank's website. But I believe no bank does something like that and in my opinion that's good as there are way too many people out there who are far too trustworthy and we all know how many information they give out on Facebook & Co. Now imagine a facebook<->bank integration... M.Zuck.'s wet dreams which hopefully never become true... And even if it's not Facebook.. There'll always be companies who want people's personal data and enough people giving them out; especially if it's easy and looks secure ("I have to confirm it on MY BANK's page. so it MUST be safe - it's supported by MY BANK").

Is there a secure way to remove a user field from a login dialog? [closed]

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 1 year ago.
Improve this question
Browsing through Coding Horror, I saw this article on removing the user field from a login dialog.
It's an interesting concept albeit an old one from 2005. Nevertheless, I started thinking about it and wondered:
How would you be able to do this in a secure fashion?
If you identify the user by their password that means all passwords must be unique - yes?
If all passwords must be unique, what do you do when someone enters a password that's already in use?
You can't tell them it's already in use because that would give away someone else's login.
I can't think of a way one could implement this in a secure fashion...any ideas?
You do not identify users by password, you identify them by user name. You authenticate users by password. Just think a bit what does it mean to identify by password. I join the system, he asks me to enter my new password. I say 'foo', he says 'foo is already in use'. I say 'tyvm'', and open the login window. When prompted I simply enter 'foo' and he says 'Welcome Mr. President'...
No, there absolutely cannot be a requirement to have passwords unique, that would be a huge security hole in any system because it relies on information disclosure to function: by reveling a duplicate you disclose somebody's password. Even with name/password combinations, once you disclosed that 'password is in use' all I have to do is iterate through the list of accounts trying the password you just revealed to me, and one combination will succeed.
My first thought, which is also alluded to in the article, is to increase the password complexity requirements to avoid collisions.
16-byte GUIDs avoid collisions (every star can have 6.8×1015 GUIDs) well enough, so it shouldn't be too difficult. Obviously human-generated input isn't quite as random, but if you add in enough requirements like lowercase/uppercase/numbers/symbols/length, it might work well enough.
Well, I suppose you could look for some other piece of "uniquify-ing" data, to use in combination with the password. For a web app, this could be a hash inserted in a cookie, from a previous visit. It'd be hard to guarantee uniqueness (multiple users from a single profile on a single computer, for instance).
My bank takes essentially this approach, with my public IP address. It's a little annoying, actually. Every time my DHCP lease expires, my bank's website "un-recognizes" me, and asks one of several security questions, before I get the standard username/password screen.
Multiple-factor security uses something like this (a hardware key or hardware-provided identifier, in combination with a password).
This approach strikes me as overly clever, and clever's rarely the right way to approach security systems.
I believe you cant.
By entering your username you are providing your identity, by entering your password you are providing a means for the server to verify this identity.
Both are inherently required unless you have some other means of determining identity (IP, keycard, etc.)
Basically you cant expect anyone to believe you are who you say you are, when you don't say who you are!

How to collect customer feedback? [closed]

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 9 years ago.
Improve this question
What's the best way to close the loop and have a desktop app "call home" with customer feedback? Right now our code will login to our SMTP server and send me some email.
The site GetSatisfaction has been an increasingly popular way to get customer feedback.
http://getsatisfaction.com/
GetSatisfaction is a community based site that builds a community around your application. Users can post questions, comments, and feedback about and application and get answers to their questions either from other members or from members of the development team themselves.
They also have an API so you can incorporate GetSatifaction into your app, and/or your site.
I've been playing with it for a couple of weeks and it is pretty cool. Kind of like stackoverflow, but for customer feedback.
Feedback from users and programmers simply is one of the most important points of development in my opinion. The whole web2.0 - beta - concept more or less is build around this concept and therefore there should be absolutely no pain involved whatsoever for the user. What does it have to do with your question? I think quite a bit. If you provide a feedback option, make it visible in your application, but don't annoy the user (like MS sometimes does with there feedback thingy on there website above all elements!!). Place it somewhere directly! visible, but discreet. What about a separate menu entry? Some leftover space in the statusbar? Put it there so it is accessible all the time. Why? People really liking your product or who are REALLY annoyed about something will probably find your feedback option in any case, but you will miss the small things. Imagine a user unsure about the value of his input "should I really write him?". This one will probably will not make the afford in searching and in the end these small things make a really outstanding product, don't they? OK, the user found your feedback form, but how should it look and what's next? Keep it simple and don't ask him dozens questions and provoke him with check- and radioboxes. Give him two input fields, one for a title and one for a long description. Not more and not less. Maybe a small text shortly giving him some info what might be useful (OS, program version etc., maybe his email), but leave all this up to him. How to get the message to you and how to show the user that his input counts? In most cases this is simple. Like levand suggested use http and post the comment on a private area on your site and provide a link to his input. After revisiting his input, make it public and accessible for all (if possible). There he can see your response and that you really care etc.. Why not use the mail approach? What about a firewall preventing him to access your site? Duo to spam in quite some modern routers these ports are by default closed and you certainly will not get any response from workers in bigger companies, however port 80 or 443 is often open... (maybe you should check, if the current browser have a proxy installed and use this one..). Although I haven't used GetSatisfaction yet, I somewhat disagree with Nick Hadded, because you don't want third parties to have access to possible private and confidential data. Additionally you want "one face to the customer" and don't want to open up your customers base to someone else. There is SOO much more to tell, but I don't want to get banned for tattling .. haha! THX for caring about the user! :)
You might be interested in UseResponse, open-source (yet not free) hosted customer feedback / idea gathering solution that will be released in December, 2001.
It should run on majority of PHP hosting environments (including shared ones) and according to it's authors it's absorbed only the best features of it's competitors (mentioned in other answers) while will have little-to-none flaws of these.
You could also have the application send a POST http request directly to a URL on your server.
What my friend we are forgetting here is that, does having a mere form on your website enough to convince the users how much effort a Company puts in to act on that precious feedback.
A users' note to a company is a true image about the product or service that they offer. In Web 2.0 culture, people feel proud of being part of continuous development strategy always preached by almost all companies nowadays.
A community engagement platform is the need of the hour & an entry point on ur website that gains enuf traction from visitors to start talking what they feel will leave no stone unturned in getting those precious feedback. Thats where products like GetSatisfaction, UserRules or Zendesk comes in.
A company's active community that involves unimagined ideas, unresolved issues and ofcourse testimonials conveys the better development strategy of the product or service they offer.
Personally, I would also POST the information. However, I would send it to a PHP script that would then insert it into a mySQL database. This way, your data can be pre-sorted and pre-categorized for analysis later. It also gives you the potential to track multiple entries by single users.
There's quite a few options. This site makes the following suggestions
http://www.suggestionbox.com/
http://www.kampyle.com/
http://getsatisfaction.com/
http://www.feedbackify.com/
http://uservoice.com/
http://userecho.com/
http://www.opinionlab.com/content/
http://ideascale.com/
http://sparkbin.net/
http://www.gri.pe/
http://www.dialogcentral.com/
http://websitechat.net/en/
http://www.anymeeting.com/
http://www.facebook.com/
I would recommend just using pre built systems. Saves you the hassle.
Get an Insight is good: http://getaninsight.com/

Resources