My company has a website that is used by internal and external users. Certain information is not able to be seen by external users. However, if they add something to the URL (ie. ?ParentRsvId=4794094), they are able to pull up that reservation and view it. How can I stop that from happening?
As a general rule, you have no control over the client in a WebApplication. You can tell it that something should be done, but you can never asume it is actually done. So JavaScript will not help you 1 Iota her.
About your only way to block areas and ensure sensible requests, is via Programm flow on the server side:
In your case, the Reservation View should check if the Logged in User account is supposed to be there. And if it is not, you simply send a redirect to the login page/error message. The client can either follow the redirect. Or stay on the redirect page. In both cases, no information is leaked.
You need to have authorization checks on the server-side code that generates the page content. When rendering the page, check that the user has access to view the content and if not show a 401 error or redirect to a page that they have the authorization to see.
Related
I read How does XSS work? but I still don't get this point .
Scenario :
I run mybank.com site and an end user logs in to the site .
Someone "injects" malicious code by submitting a GET that gets printed or echoed back .
As far as I know your requests always goes to mybank.com because of cross domain request's disallowed by default .
So how do I actually manage to sent contents to mysite.com assuming mysite is a malicious user's site who wants to exploit mybank.com's XSS vulnerabilities ?
If I can't change point 3 , then probably there is no way I could do 4 . But if 4 can be done is it done by changing window.location.href or document.location i.e breaking assumption 3 ? Now it behaves like it is mysite.com ?
Or is there any other way you could hijack site without 4 ?
Once the code gets injected, there is no "security", the browser thinks that all the code that is running on the site belongs there.
Think about what you can do in your own web pages when you code. You can have JavaScript click on buttons, submit forms, click links, etc. You can have the code inject elements, more code, remove things, etc.
So imagine what a developer can do to an email app or a bank account. They could send emails or transfer money. Just need to fire the right steps.
Now how can they transfer information out? As simple as making a GET or POST request. They set up an end point somewhere and make a request to it. The end point logs the data. Requests can be made with AJAX, images, form submissions, loading up ifrmaes, etc.
Cross Domain requests are allowed if the other domain you want to talk to allows it.
GET requests are simple requests you can make just by loading a URL. Suppose the vulnerable page allows you to send a money order to someone using a pure GET request like this:
http://bank.com/sendmoney?user=attacker&amount=everything
Just by navigating to the URL means you want to send all of your money to the attacker (lol)... Suppose the only security is that you must be logged into bank.com
Now suppose you visit this attacker's website while logged into bank.com and he has an img element with the src attribute set to that URL. Just by visiting the page you've sent all of your money to the attacker. That's it in a nutshell.
Usually XSS means you are able to actually inject code directly onto the page because of the logic used on the server-side echo's the contents of a GET-request variable directly onto the page without sanitizing the input. Hopefully this helps you understand a little better.
I'm making a google-chrome-extension for a certain website, and want the browser_action to display the number of notifications a user has received on said website.
Currently, I am using an ajax request to retrieve the HTML from the website/messages page, and then I am using jQuery to count the number of "#unread > li" elements in that HTML (each one representing a new message.)
Now, I take this number and display it on the browser_action icon.
All works perfectly, the correct amount of messages are notified, BUT the user must be logged in on the site (not my site) for it to work properly, otherwise they will think that they have no messages.
I was thinking that I could detect if the user is logged in, and if not display a red ! exclamation mark on the icon. Then, when the user clicks to show the pop-up, it asks them to log in.
However, I have no idea how to actually log the user in to the website using this method: how do I send the credentials across? Or does the website have to support a request like this?
TL;DR
How can I log a user into a website I don't own remotely?
Disclaimer: I've never done a google chrome extension, but based on the rest of your question, it sounds like it's just working with JavaScript like any other web page, so I'll go ahead and answer it.
In any case, working with cookies in JavaScript can be somewhat of a pain:
https://developer.mozilla.org/en-US/docs/Web/API/document.cookie
http://www.perlscriptsjavascripts.com/js/cookies.html
I'm assuming that your server side already works with and expects cookies, so I won't try to suggest any alternatives. That being the case, your server is what needs to validate the cookie, so, IMHO, might as well set the cookie on the server side. If the server handles it, on the JS side, you simply post the username/password to a server-side page, e.g.
$.post("/user/login",{"Username":"foo","Password":"bar"},callback);
That server-side page validates the username/password and then, if successful, generates the cookie and sends a response back to the JavaScript (e.g. {"IsSuccess":true}). Upon receiving a successful response rather than an error, you just start calling the other web services to retrieve your data assuming you are logged in and build out the page.
Assuming that your web services will return HTTP error codes that help you determine a problem with the session, if you get a 401 error code, you take the user back to the login page. If you get a 403 error code, you let the user know they can't access that data...etc., all depending on your app.
Ultimately, JavaScript doesn't know whether a user is actually logged in, so you have to rely on the server to send you information in a way that is understandable so that you can direct/prompt the user as necessary.
[Edit: 2014-11-21]
You didn't answer my other question: what do you get back? If they don't set the cookie themselves at the login, then you need to get back the session token from the response they send...if they don't send you a session ID, you're SOL. If they do send you an session token/session ID, then you need to know what to name it (e.g. PHP uses something like PHPSESSID as the cookie name, but it can be whatever the coders of that domain decided on). Beyond that, you have to be able to set the cookie for THAT domain name (3rd party cookie). This may have mixed results depending on the user's settings--if they block 3rd party cookies--however, since this is a google extension and not a website, maybe it's able to bypass that kind of restriction. I know that FireFox's developer toolbar is able to manipulate cookies for all domains, so it would be a reasonable assumption you would be able to as well.
I've been fumbling around with different client side technologies, like AngularJS, EmberJS, even trying to use straight JQuery and figure out how to use ReactJS with it. That aside, my goal is to build a single page app using json in between the client and a Java Jersey 2 jax-rs back end api.
I have two stumbling blocks right now. Some info though..I am deploying my app as a WAR file in Jetty. My back end is java based. I am using only jquery in the client side as of now.
My main stumbling block is how to handle login, logout and session management. With an rest API and using ajax, I have login working, including it setting a cookie. My concern however is with a single page app, there is just the one index page, and if the user closes the browser, then reopens it to the index page while the cookie/session is still good, the user should be logged in, not see the outside (not logged in) page. I am unsure how to handle this, whether it be a jsp page, index.html with some templating library, etc. With JSP I can insert some scriplet code (against my better judgment). In the old days I'd include a header that would check for request.getSession().getAttribute("user") and if it was there..the user was logged in and using scriplet if() code I'd display a logged in header, instead of the non-logged in header. But I am in the belief there has got to be a better way to do this with todays client side JS frameworks.
The other stumbling block is the navigation and dynamic aspects. For example, when I was messing around with angular js, it was easy enough to use Welcome {{name}} and within the scope replace name with a json response value for the logged in user. In my current situation, I am not exactly sure how to best go about displaying dynamic bits like this with pure jquery other than using some sort of $("#elem-id").innerHtml="..." code within the response success method of an ajax call. As well, I am not quite sure how to handle navigation to different pages. My logged in site will have some drop down menus or links that will replace the content area with different varying amounts of content.
So first, what are some ways in a SPA to handle user sessions, in the case of a page reload, or close/crash browser restart.. to ensure the user is still logged in and direct them to the right page? Second, what sort of templating and routing/navigation options exist that don't require me to put a huge ton of code in my one index.jsp page?
Thank you.
If you're having a REST API as the back end, then you must have implemented oAuth as an authentication mechanism. That is, when your user logs in, using a username and a password, you exchange that data with an authentication token. This authentication token is sent your server with each and every API call and your backend validates this token before servicing the request. Clear so far?
What you could do is, when you obtain the access token, you can also obtain the access token expiration time from the server and store that data in your client side app. In localStorage maybe? And when your user closes the browser and reopens again, you can first check whether such access token is available (and not expired) before asking the user to log in. This should solve your first problem.
Secondly, if you're looking for a lightweight routing option, I recommend director.
I am building a similar application. OAuth is not mandatory. You can have normal sessions etc by hitting the jersey login endpoint and setting a session and a cookie "keepme" with the session if user wants to be persistently logged in. You can then have a jersey AuthFilter for example check if either there is a cookie with a valid session or an active session and keep the user logged in.
Your frontend application should have no say over this, just communicate with the server and if it doesn't get unauthorized access (from the AuthFilter) then continues otherwise it displays the login page.
In my work with a Javascript single page application, i have recently run into a problem.
The whole idea behind this project, is to avoid page reload. When the user comes to my application they won't need to make any reloads. This is done with jQuery and Backbone.js and PHP as service.
I have this static index.html file, where i hide my login container and application container. Then i show the login container, if the user is not recognize by my application, and if they have auth i show the application.
if auth:
application.show()
elif not auth:
login.show() // like Gmail or Facebook etc.: Information + login-form
I wan't to show users who aren't authenticated, both login-form and general info. Very important is also that the site can be found by robots as Google etc.
Can this only be done with 2 different files, giving me reload? A site.com and login.site.com. That solution irritates me, because my login, as it is by now, is quite instant.
Not sure I get the question completely but if you want to check if a user in authenticated, try to do an ajax call. If it fails with "401 unauthorized" the user needs to login...
You can achieve what you want by using ajax calls to authenticate (Although this is not a recommended approach, and people usually prefer the two page solution you have outlined).
What you can do, is have very skinny controllers that just exist to provide data to rich client UI.
Your gateway controller(A separate controller, with no model that acts as an entry point in the application) will just render the basic application structure to the client (without any user specific data, you dont know if the user is logged in, you dont need to know at this point). Then the client will query the UserController for identity of currently logged in user, if user is logged in server returns a json response containing information related to user and if not, server returns a response saying that user is not logged in. Then you can fetch a partial for the login form and then submit it again through ajax. As you see, creating the UI once and communicating with the server with lightweight ajax calls can solve your issue easily.
Just want to get input from people who know. I was considering CSRF vulnerabilities, and the seemingly the most popular method I know to fight against it. That method is to create a token in the returned html and adding a cookie with the same value. So if a script tries to do a post they would have to guess the token thats embedded in the web page for it to be successful.
But if they're targeting a specific website why can't they just use a script that
Calls a get on the page (the cookie will be returned even though the script can't access it)
Parses the html and gets the token
Calls a post with that token in it (the cookie that came back will be sent back)
They've successfully submitted a form without the users knowledge
The script doesn't need to know the contents of the cookie, it's just using the fact that cookies get sent back and forth all the time.
What am I missing here? Is this not possible? I think this is pretty scary if you think about it.
Below this line is not required reading to answer the question :)
This vulnerability banks on the fact that authentication is done based on cookies, which I think is the main way authentication is currently occurring.
Another solution I can think of is making authentication be on the page level. So
when they log in the returned html will have that token in it. every link that they click contains that token so when the web server gets a request it has a way to identify the user/session. The problem with it is that if they use any navigation other than that they will be 'unauthenticated'(e.g. type in a url) , also it doesn't look nice in the url because it would probably look something like this:
https://www.example.com/SuperSecretPage/1/123j4123jh12pf12g3g4j2h3g4b2k3jh4h5g55j3h3
But I do understand that if safety is more important, then a pretty URL is second place.
I don't know everything about cookies but what if user agents were a little more careful with their cookies?
For example, what if the cookies sent depended on the tab? We all surf using tabs by now, right? so what if the scope of the cookie was the tab? so if i have my banking site open on tab 1 and i'm surfing on tab 2, any scripts calling gets/posts on
tab 2 will only send the cookies accrued in tab 2.
Or what if cookies were stored / domain. So while I'm on example.com any cookies that come back go into the example.com cookie collection. and then when i'm on www.mybankingsite.com all the cookies get put into the mybankingsite.com collection. So if I go to example.com and it runs a script that calls a get/post the user agent will only send example.com cookies. This is different than sending the cookies of the requested domain. E.g. if a script calls a get of mybankingsite.com within a web page of example.com the user agent will not send the mybankingsite.com cookies.
I know i have no control over what user agents do, but I'm just exploring possibilities
So I think the problem here becomes the attacker's attempt to get the page's contents. To get the authenticated user's page, the attacker needs to be able to send a request on their behalf and read the contents. AJAX won't send cross-domain requests, iframes won't let you read the response. I am struggling to think of other ways in which an attacker would get the contents first.
A more likely hack is using clickjacking to have the user just submit the form. This technique doesn't seem too likely. (caveat: it's security, we can always be wrong.)
Does anyone care to share some code on this issue as I just hacked my own site (Not in production) with CSRF. All I had to do was the following
At: www.badguy.com/ write the following html
img src="www.goodguy.com/secure/user/delete/5">
What this does
So the admin goes to to www.badguy.com/ and the the image makes a request to
www.goodguy.com/secure/user/delete/5 from the users browser so the admin unknowingly just deleted a user. If you create a loop your in some trouble. Expect I never delete data just change its status :) but still I don't like the looks of this.
The CSRF token has to be unique per session. If a malicious server requests the same page, they will get a different token. If they try to request the contents of the page via JavaScript on the client's machine, the same-origin policy will prevent them.