I have a web page A created by a PHP script which would need to use a service only available on another page B – and for various reasons, A and B can't be merged. In this particular instance, page A is a non-WordPress page and page B is WordPress-generated. And the service in question is sending emails in a specific format which is supplied by a WP plugin.
My idea is to use page A to generate the email content and then send that content to page B which then, aided by the plugin, sends the email in the appropriate format and transfers control back to page A. This would be perfectly doable – but what I would like in addition is for page B never to be displayed. The visitor should have the impression that they are dealing only with page A all the time. Can that be done and if so, how?
I do not intend this to be a WordPress question (although maybe it is), rather more generally about using another page's script in passing without displaying that other page.
If you do have source access, it would be most reliable to use the addon directly... But if you cannot, the second easiest would be to use curl to mimic the form post on page B. This would happen server side so the user wouldn't see it happening.
To figure out what you need to send in your POST request, open your browser's developer tools and watch the network tab when you send the form manually, take the URL, and all the post data. Then you'll be able to mimic it.
You may proxy https://SITEA.com/siteB/whatever to http://SITEB.com/whatever - or the other way around... I didn't fully understand the process :P
In case you just want the siteB service call, you may also send the requests via curl or a HTTP library of your choice - which might be better as you will have to get a nonce first and stuff like that.
Related
First of all: I don't know anything about AJAX or similar. Please keep that in mind.
Question is above. I am trying to parse information from a website (http://www.sportstats.com/soccer/germany/bundesliga/). More specific: I want to parse the information which is held by the <table id="nextMatches_0">. I found out that this is not possible with the Library I used until now: Jsoup, because the website gets the information from outside. Until now I think that it's AJAX which is fillig in the table.
Though I didn't find a way to parse the information I want, it would be great to just make the same thing the website does and send a request to the server. But I don't have a clue how I could do this, which is why I am asking for help.
Big thanks already :)
It sounds like you're trying to reverse engineer how some data gets into a web page so you can figure out how you can get that same data from your Javas app. So far, you've concluded that the data itself is not in the HTML so your guess is that some script in the web page is putting the data into the page via an Ajax call.
First off, to confirm whether that is the case, you can do two things:
Bring up that page in the web browser and do View/Source. Examine the original HTML of the page and see if the content you want is in there. If it is, then you can just do a direct request from the server to get that page, parse the HTML and then grab your content. If the content you want is not in the original HTML of the page, then go to step 2.
Open the Chrome debugger. Switch to the network tab. Then, load your page into the browser. Examine the requests in the network tab and find all the request that list their "type" as "xhr". These will be the ajax requests from that page. I see at least 3 xhr requests in that page. Then examine each xhr request to see if it is the one requesting and receiving the specific data you are interested in. If you find it, then you can study how the request is formed to see if you can send that same request to the same source from your Java app.
If, in the first step you find the data is actually in the HTML, then you can just request that link from your Java, get the HTML, put it into an HTML parser and then find the content you want in the parsed page.
If, in the second step, you conclude there is an Ajax call that is fetching the data you want, then you need to see how the request is formed and what host it is sent to and copy that type of request from your Java app to see if you can obtain the same data. I see that page contains a couple Ajax calls that are fetching JSON. If one of those is what you want, then you would parse the JSON in your Java app so you could then access the data from your Java code.
Oh, and I'd suggest reading the licensing information on the site to see what you are actually allowed to do with someone else's content or Ajax calls.
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 am creating a website with ASP.NET MVC 4. The application consists of two pages, whose workflow is similar to Google Maps. On the first page, the user types in a patient's name, date of birth, and some basic data about that patient. Then the user submits the form, and is brought to the second page in the application. The second page is just a print preview that the user can print. I want the user to be able to navigate between the two pages using the browser's back and forward buttons (for example, to change inputs on the first page after seeing the second page)
Actually calculating the data that appears on the printout is very complicated, and I really want to have all that code be executed server-side, where I can use C#. So I need to send the patient's data to the server. The problem is that I don't have an SSL certificate, and I don't want to send a patient's name with their data over HTTP (as this is a violation of privacy). I am willing to send the patient's data over HTTP, as long as it remains detached from the patient's identity (except for at the client). The name and date of birth are simply displayed in the corner of the printout, and do not affect the server-side calculations in the least.
I can think of two possible ways to accomplish this task. The first, more preferred solution, would be a way to send only some of the form data over HTTP, yet still somehow get the name and date of birth from the first page in client-side jquery running on the second page. Maybe I can make a cookie and somehow specify not to send it as part of the http request?
The other way to accomplish this is to make the entire application into a single page, and dynamically change the contents via client-side jquery. In this solution, when the user submits the form, I can fire off an ajax request that will return JSON. I can then populate the print preview with data returned from the server (i.e. the JSON) as well as from the form (i.e. the patient's name and date of birth). Is there a way to accomplish this while still allowing the user to use the browser's back and forward commands to navigate between the data input page and the print preview page if they are in fact the same page?
I don't believe what you described is possibly without severe drawbacks. Sure, you could roll up the data into a cookie or local storage and avoid the POST--but this is a lot of logic in your view, and a pretty nasty hack.
The options I would advise are:
Get an SSL cert. If that's the driving force behind your approach then spend the $6 to get one. Seriously.
Keep the print view in the same page as the form; use css #media types to specify the print styles.
I'm building a website that is functionally similar to Google Analytics. I'm not doing analytics, but I am trying to provide either a single line of javascript or a single line iframe that will add functionality to other websites.
Specifically, the embedded content will be a button that will popup a new window and allow the user to perform some actions. Eventually the user will finish and the window will close, at which point the button will update to a new element reflecting that the user completed the flow.
The popup window will load content from my site, but my question pertains to the embedded line of javascript (or the iframe). What's the best practice way of doing this? Google analytics and optimizely use javascript to modify the host page. Obviously an iFrame would work too.
The security concern I have is that someone will copy the embed code from one site and put it on another. Each page/site combination that implements my script/iframe is going to have a unique ID that the site's developers will generate from an authenticated account on my site. I then supply them with the appropriate embed code.
My first thought was to just use an iframe that loads a page off my site with url parameters specific to the page/site combo. If I go that route, is there a way to determine that the page is only loaded from an iframe embedded on a particular domain or url prefix? Could something similar be accomplished with javascript?
I read this post which was very helpful, but my use case is a bit different since I'm actually going to pop up content for users to interact with. The concern is that an enemy of the site hosting my embed will deceptively lure their own users to use the widget. These users will believe they are interacting with my site on behalf of the enemy site but actually be interacting on behalf of the friendly site.
If you want to keep it as a simple, client-side only widget, the simple answer is you can't do it exactly like you describe.
The two solutions that come to mind for this are as follows, the first being a compromise but simple and the second being a bit more involved (for both you and users of your widget).
Referer Check
You could validate the referer HTTP header to check that the domain matches the one expected for the particular Site ID, but keep in mind that not all browsers will send this (and most will not if the referring page is HTTPS) and that some browser privacy plugins can be configured to withhold it, in which case your widget would not work or you would need an extra, clunky, step in the user experience.
Website www.foo.com embeds your widget using say an embedded script <script src="//example.com/widget.js?siteId=1234&pageId=456"></script>
Your widget uses server side code to generate the .js file dynamically (e.g. the request for the .js file could follow a rewrite rule on your server to map to a PHP / ASPX).
The server side code checks the referer HTTP header to see if it matches the expected value in your database.
On match the widget runs as normal.
On mismatch, or if the referer is blank/missing, the widget will still run, but there will be an extra step that asks the user to confirm that they have accessed the widget from www.foo.com
In order for the confirmation to be safe from clickjacking, you must open the confirmation step in a popup window.
Server Check
Could be a bit over engineered for your purposes and runs the risk of becoming too complicated for clients who wish to embed your widget - you decide.
Website www.foo.com wants to embed your widget for the current page request it is receiving from a user.
The www.foo.com server makes an API request (passing a secret key) to an API you host, requesting a one time key for Page ID 456.
Your API validates the secret key, generates a secure one time key and passes back a value whilst recording the request in the database.
www.foo.com embeds the script as follows <script src="//example.com/widget.js?siteId=1234&oneTimeKey=231231232132197"></script>
Your widget uses server side code to generate the js file dynamically (e.g. the .js could follow a rewrite rule on your server to map to a PHP / ASPX).
The server side code checks the oneTimeKey and siteId combination to check it is valid, and if so generates the widget code and deletes the database record.
If the user reloads the page the above steps would be repeated and a new one time key would be generated. This would guard against evil.com from page scraping the embed code and parameters.
The response here is very thorough and provides lots of great information and ideas. I solved this problem by validating X-Frame-Options headers on the server-side , though the support for those is incomplete in browsers and possibly spoofable.
I've been looking for better ways to secure my site. Many forums and Q/A sites say jquery variables and HTML attributes may be changed by the end user. How do they do this? If they can alter data and elements on a site, can they insert scripts as well?
For instance I have 2 jquery scripts for a home page. The fist is a "member only" script and the second is a "visitor only" script. Can the end user log into my site, copy the "member only" script, log off, and inject the script so it'll run as a visitor?
Yes, it is safe to assume that nothing on the client side is safe. Using tools like Firebug for Firefox or Developer Tools for Chrome, end users are able to manipulate (add, alter, delete):
Your HTML
Your CSS
Your JS
Your HTTP headers (data packets sent to your server)
Cookies
To answer your question directly: if you are solely relying on JavaScript (and most likely cookies) to track user session state and deliver different content to members and guests, then I can say with absolute certainty that other people will circumvent your security, and it would be trivial to do so.
Designing secure applications is not easy, a constant battle, and takes years to fully master. Hacking applications is very easy, fun for the whole family, and can be learned on YouTube in 20 minutes.
Having said all that, hopefully the content you are containing in the JS is not "mission-critical" or "sensitive-data". If it is, I would seriously weigh the costs of hiring a third party developer who is well versed in security to come in and help you out. Because, like I said earlier, creating a truly secure site is not something easily done.
Short Answer: Yes.
Anything on the users computer can be viewed and changed by the user, and any user can write their own scripts to execute on the page.
For example, you will up vote this post automatically if you paste this in your address bar and hit enter from this page:
javascript: $('#answer-7061924 a.vote-up-off').click();
It's not really hacking because you are the end user running the script yourself, only doing actions the end user can normally do. If you allow the end user on your site to perform actions that affect your server in a way they shouldn't be able to, then you have a problem. For example, if I had a way to make that Javascript execute automatically instead of you having to run it yourself from your address bar. Everyone who came to this page would automatically upvote this answer which would be (obviously) undesired behavior.
Firebug and Greasemonkey can be used to replace any javascript: the nature of the Browser as a client is such that the user can basically have it do anything they want. Your specific scenario is definitely possible.
well, if your scripts are public and not protected by a server side than the Hacker can run it in a browser like mozilla.
you should always keep your protected content in a server side scripting and allow access by the session (or some other server side method)
Yes a user can edit scripts however all scripts are compiled on the user's machine meaning that anything they alter will only affect their machine and not any of your other visitors.
However, if you have paid content which you feed using a "members-only" script then it's safest if you use technology on the server to distribute your members-only content rather than rely on the client scripts to secure your content.
Most security problems occur when the client is allowed to interact with the server and modify data on the server.
Here's a good bit on information you can read about XSS: http://en.wikipedia.org/wiki/Cross-site_scripting
To put it very simply:
The web page is just an interface for clients to use your server. It can be altered in all possible ways and anyone can send any kind of data to your server.
For first, you have to check that the user sending that data to your server has privileges to do so. Usually done by checking against server session.
Then you have to check at your server end that you are only taking the data you want, and nothing more or less and that the data is valid by validating it on your server.
For example if there is a mandatory field in some form that user has to fill out, you have to check that the data is actually sent to server because user may just delete the field from the form and send it without.
Other example is that if you are trying to dynamically add data from the form to database, user may just add new field, like "admin", and set it to 1 and send the form. If you then have admin field in database, the user is set as an admin.
The one of the most important things is to remember avoid SQL injection.
There are many tools to use. They are made for web developers to test if their site is safe. Hackbar is one for example.