I did read every article on the first page of google search. At best, there's something vague like it removes script tags and other harmful content. Is that basically all it does? What is this "other harmful content"?
What's the end goal here, what's my concern?
What is this normally even used for? Is it reasonable to use it if we let a user enter a long string that might contain html? Or is it only for when we are explicitly letting the user generate html?
For example's sake, Alice might have an SPA in where she lets her users type in code snippets that are also executed in the same page, which are also shown to other users who visit the page as well.
Bob decided to insert a malicious snippet that let him get information on those who view those pages, via putting in an HTTP request to his own end with the viewer's credentials, i.e account username and session ID in the frontend, or an external script that does the same.
Alice viewed the page, after all she's curious on what her users have been doing! Little did she know that Bob now has access to her session ID with elevated privileges.
Bob then continues on to access the app with the said session ID, elevates his own account to Administrator privileges, kicks out Alice's account and helps himself to the information inside... possibly credit card account details. I'm just weaving on the spot but you get the idea.
In a nutshell you shouldn't trust all user input when you're letting them render it. That is what ngSanitize for, to keep you from unwanted code execution.
Related
I am trying to learn BDD cucumber and i am trying to write a feature file for login scenario with valid and invalid usernames.
For valid user will be logged and will logout however for invalid username, the user will be asked to go to login page again and asked to write correct credentials.
I would like to ask, can we have both positive and negative scenarios in "Scenario Outline"?
Could you please help me in writing perfect feature file for this simple scenario?
Take a look at my feature file code ( PS, I am a beginner :))
Feature: Login Action
Description: This feature will test a LogIn and LogOut functionality
Scenario Outline: Login with valid and Invalid Credentials
Given User is on Home Page
When User navigate to Login Page
Then User enters "<username>" and "<password>"
And Keeping case as Valid
Then User should get logged in
And Message displayed Login Successfully
Then User enters "<username>" and "<password>"
And Keeping case as InValid
Then user will be asked to go back to login page
And Provide correct credentials
Examples:
|username|password|Case|
|abc#gmail.com|12345|Valid|
|abc1#gmail.com|dfsd2|InValid|
Scenario: Successful logout from application
When user logs out from application
Then Message displayed Logout successfully
And Browser quit by driver
'Perfect' - Ain't no such thing...
The ScenarioOutline you have written is very confusing and possibly a wrong interpretation of how scenariooutline works. Basically you are logging in twice with each row of the examples table ie. same username and password (line 3 and 7 in the SO). In a scenariooutline all the steps will be repeated with each row of data that u provide in examples. Refer to multiple tutorials available.
Why mix up valid and invalid logins? Keep them in separate scenarios. Easy to follow.
Move the logout to a separate feature file.
Then you can move the first 3 steps of the login scenario into a background. Reduces repetition.
You are going to have a problem with checking login functionality for the valid case for multiple data. Once a valid user logs in then most web applications store the login credentials in a cookie etc etc. So when a new request is made for login page it might just skip the login page and land up in maybe lets say home page. Then you will get the NoSuchElementException when the selenium code looks for the userid input box. So for valid cases you need to have a logout too.
#Login
Scenario Outline: Login with valid and Invalid Credentials
Given User is on Home Page
....
....
#Valid
Examples:
|username|password|Case|
|abc#gmail.com|12345|Valid|
#InValid
Examples:
|username|password|Case|
|abc#gmail.com|12345|Valid|
To run the Valid Login cases use the tags option in runner as {"#Login","#Valid"} or if on cucumber 2 #Login and #Valid. For Invalid one replace with #InValid.
As pointed out here in an excellent answer - each scenario is essentially one test case and must therefore be clearly separated.
Nevertheless, it's critical to understand that Given/When/Then (in their most basic essence) are equivalent to the traditional three stages of a system test: Arrange/Act/Assert, therefore:
Given: Arrange the system in a known state
When: Command the system (what you want to test)
Then: Assert that the outcome was what you expected.
That's it! (of course there's a lot more to BDD than that - but these are the basics of an executable specification)
Given User is on Home Page is not arranging the system in a known state, but Given I am registered is. Though it might not be enough to state just this, because as soon as you go through the whys and whats of the scenario you'll quickly realize that you're missing something more concrete as an example.
To paraphrase the previous answer:
Given I am registered -> set up the user (but does it matter who?) as being registered in the system (database entry?), registered for what? does it matter to the outcome?
When I sign in -> Give the system the command to sign-in (who?) - this might be done via a web form or via an API (or over the phone?). Does it matter what time you sign in, can you sign in immediately?
Then I should be signed in -> Check response from web app, database, session? cookie?
Saying that, logging in scenarios are probably not worth using BDD to tackle since they are as well defined as CRUD - there's almost no need for analysis.
Scenario: Good sign in
Given I am registered
When I sign in
Then I should be signed in
Scenario: Not registered sign in
Given I am not registered
When I sign
Then I should not be signed in
And ...
Scenario: Registered with wrong password
Given I am registered
When I sign in with a bad password
Then I should not be signed in
And ...
Tips:
Keep things simple
Don't use outlines
Keep details of HOW you do things out of scenarios
Have one scenario for each path
10 simple scenarios are better than one complex one.
You can see details of how to write scenarios like this (in Ruby) at https://github.com/diabolo/cuke_up/tree/master/features.
Caveats:
this is just one persons opinion
you need to be able to write code to work this way (as you push all the details of how things are done out of cucumber and into helper code).
registration is a pre-requisite to sign in
I need to put a link into email. When user clicks on it, angularjs app should open specific page and entity. I suppose that the link should contain id of the entity. This allows to find the record on backend side and then open page.
Is it safe to publish such a link in email(I mean id of the record in DB)? Do we need to hash id?
I don't really see much trouble.
There are a lot of web pages (angular or not) which provides direct links to pages using the entity id as parameter.
In the case of angular, when another - non-authorized - user tries to enter, it will ask the backend, the backend with reject its petition and you can redirect the user to the home page. So if some user tries to access that route, he well just see the home page.
It is also true that in general (I mean, not angular specifically) some people likes to hash the id, but I don't see that as really needed.
So it comes down to the use case / personal preference. From the point of security, your backend won't give any entity even if you know every piece of it. You need to be logged in AND able to retrieve it.
I'd like to create visualforce page that inserts a record into salesforce account object. However, I expect some of the page users won't have salesforce accounts. Can they still access it? If not, what are the alternatives that can be used to visualforce page in this case? (Please don't consider Web to Lead Forms).
Thanks,
Yes, it's possible. Go read about Salesforce Sites. For a start:
http://wiki.developerforce.com/page/Websites
http://wiki.developerforce.com/page/An_Introduction_to_Force.com_Sites
(of course it's also possible to write that page in say Java/.NET/PHP and use integration via SOAP or REST to talk to Salesforce... but these 2 main links will keep the whole solution within SF so no need to need to learn new language, have extra maintenance effort etc)
Sites are VF pages that expose a bit of your company's data without need to log in. You can use them to input data too, just remember that in theory anybody could learn the link and spam you (not too different from web2lead, inbound email handlers etc). You specify security in a way similar to Profiles, the records will have "Created By = {site name} Guest User".
I don't think there's anything out of the box to restrict visibility, they're open to whole world. So if you would want something similar to login IP ranges (so only sales reps from your office's network can enter data) - you might have to write some logic in the controller.
Anyone have any ideas on how I could get a unique username (but not the email address) for each user. Ideally, I'd show them a page asking them to specify a username for the site, but the only way I can think of doing that is to show it to them after they've authenticated via G Accounts or OpenId. But, that requires another page, and what if they navigate away without entering anything?
As you suggest, you need to ask them after they log in for the first time. Simply redirect them to that page until they fill it out.
Consider seriously, though, if you really need a username. A lot of sites demand one, but then use it for very little - and it's inconvenient for users to have to try and choose a unique one.
I want to write a program that analyzes your fantasy baseball team and notifies you of recommended actions, possibly multiple times per day. The problem is, you aren't playing fantasy baseball on my site, you're playing on yahoo, or cbs, or espn, etc.
On the majority of these sites, fantasy teams and leagues are not public, so you must be logged in and a member of the league to see the teams in the league.
All that I need is the plain html for the team page on each of those sites to be sent to my server, where I can then parse and analyze the file and send user notifications.
The problem is that I need username/password combinations to easily get this data to my server when I need it, and I think there will be a lot of people who wouldn't want to entrust their yahoo/espn/cbs password to me.
I have come up with several possible ways to solve this problem:
The most obvious way is to ask for their credentials for the site on which their team is hosted. Then I could just programmatically log in and request the data I need. I'm guessing a number of people would be comfortable giving me their credentials, and a number of them not so much.
Write a desktop client, which the user then downloads. The client would require their credentials, but it could then basically do exactly the same thing that the server based version would do, log in, request the page, and send the page back to my server. The difference being that their password would never need to leave their desktop. Their computer would need to be on, and this program running for this method to work.
Write browser add-ons that navigate to the page I need, use the cookie that is saved from a previous login to login to the site, and send the page back to my server. This doesn't require my software to ever ask for their password, but if the cookie expires I am hosed, and I don't know much about browser add-ons besides.
I'm sure there are other options, but these are what I've come up with so far.
I have two questions:
1. What are the other possibilities for this type of task?
2. Am I over-estimating people's reluctance to give me their yahoo (for example) password? Is option (1) above the obvious choice?
It was suggested in the comments that I try yahoo pipes, and that looked like a promising suggestion so I explored it a bit. Having looked now at this, I don't think that is an option. So, it looks like I'll be going with option 1.
This is a problem I grappled with a couple of years ago when I wanted to do the same thing. Our site is http://benchcoach.com and the options we were considering were the following:
Original we considered getting the user's credentials and login. We would then log in and scrape their league and team info. The problem there is that after reading several of the various terms of service, this would definitely be violating the terms of service. On top of this, Yahoo! was definitely one of the sites we were considering and their users have email (where we could get access to sensitive data), and Yahoo! wallet. In addition, it would be pretty trivial for Yahoo/ESPN/CBS to block our programmatic logins by IP Address.
The solution we settled on (not 100% happy but it does seem to work) was asking our users to install a bookmarklet (like delicious, digg or reddit) which would post the current html page to our servers, where we could parse the data and load our database. If they were still logged into their Yahoo/ESPN/CBS account, we would direct them directly to the pages, otherwise, those sites would prompt for authentication. Clicking the bookmarklet once more, would post the page to our servers.
The pros of this approach was that we never collected anyone's credentials so any concern of security would have been alleviated. Secondly, it would make it impossible for Yahoo/ESPN/CBS to block access to our service since we would never be connecting directly to their servers but rather the user's browser would be posting the contents of their browser to our server.
The problems with this is that it takes 2 clicks to post a page to our site. For head to head leagues, we needed 3-4 pages so it would take our user 6-8 clicks to sync their league to our servers. We're still looking at options for this.
One important note is that I ran into the product manager of the Yahoo Fantasy Football site at a conference a year ago. We talked about how we were getting the Yahoo data, and he confirmed that getting credentials would violate their TOS and they may stop us. While I don't think they would have, it would have made it hard to invest time and energy to develop this only to have them block our site and pissing of users by closing their accounts.
A potentially more complicated answer could possibly be done with (for example) yahoo pipes.
Hypothetically, you create a pipe which prompts the user for their credentials and provides them with a url which contains their scraped data. They enter this URL in their site, and never have to provide their credentials directly. Even better, for the security-conscious, it would be possible to examine what the pipe was actually doing before entering any information.
The downside would be increased complexity (as well as you'd have to write and maintain the pipe). Having said that, you could provide a link directly to the published pipe from your site, to make things as easy as possible.
Option 1 is the obvious choice. People who trust your site will provide the details. There is no other way you can login to other site while screen scraping.