Global demand for software engineers continues to strain the technology sector with unfilled software engineering positions and stiff competition for hiring developers who are on the market. To attract more candidates, technology firms have increasingly been working closely with universities to recruit new graduates to fill their jobs. Universities hoping to minimize mismatches in job placement for new software developers should teach the skills and attributes that enable entry-level software developers to succeed. This paper presents a case study of hiring demands at one large, well-established technology company that reveals the most sought-after attributes in new hires. We discuss results of our interviews with five software development hiring managers and the results from a wide survey of engineers and architects from various levels and experiences. The interviews and surveys reveal that some qualifications are widely desired, and others have varying demand based on functional area, technology, or type of development. Ultimately, professional skills (e.g., teamwork) and personality traits (e.g., strong initiative) top the list of desired attributes, along with a few fundamentally broad technical skills. One key takeaway is that candidates who learn professional skills from university programs may be more readily hired into their first software engineering job than those whose education focused mostly on technical areas.

Much work in privacy focuses on educating a system’s users so they will be better armed to take action based on the benefits and drawbacks of how their data is treated. Intuitively, this makes sense; one may expect people who perceive more benefit than risk in a system will elect to use it, but our research shows that is commonly not the case. We surveyed users of a social network to quantify what they perceive as the benefits and drawbacks of the platform. Given their net “value” perceived, we would have expected those who see mostly drawbacks (or a net cost) in its use to abandon the platform for a more privacy-preserving alternative. What we found was that only 62% of individuals we surveyed acted so rationally—the remainder either chose to use a platform they felt had a negative impact on their life, or chose to abandon one that served them favorably. This result indicates there are strong factors beyond rational cost/benefit analysis that lead people to decide what social platforms they use. This means that privacy professionals must focus not only on building transparency and choice, but also constructing viable alternatives so people do not feel pressured into using a platform they see as a net loss of personal privacy.

Formative assessment in a computer architecture course is often modeled as lab exercises and written homework. In this paper, we discuss the impact of splitting large homework assignments into daily assignments for a second-year computer architecture course. We describe our motivation for the adjustment, the design goals for the change, and preliminary results showing the effect on student learning. In evaluating the impact, we analyze student homework and test scores, as well as informal and formal course evaluation surveys.

Content Security Policy (CSP) defends against Cross Site Scripting (XSS) by restricting execution of JavaScript to a set of trusted sources listed in the CSP header. A high percentage (90%) of sites among the Alexa top 1,000 that deploy CSP use the keyword Unsafe-inline, which permits all inline scripts to run— including attacker–injected scripts—making CSP ineffective against XSS attacks. We present a system that constructs a CSP policy for web sites by whitelisting only expected content scripts on a site. When deployed, this auto-generated CSP policy can effectively protect a site’s visitors from XSS attacks by blocking injected (non-whitelisted) scripts from being executed. While by no means perfect, our system can provide significantly improved resistance to XSS for sites not yet using CSP.

This paper introduces the compelled certificate creation attack, in which government agencies may compel a certificate authority to issue false SSL certificates that can be used by intelligence agencies to covertly intercept and hijack individuals’ secure Web-based communications.

This chapter contains sections titled: Online Advertising: With Secret Security Web Security Remediation Efforts Content-Sniffing XSS Attacks: XSS with Non-HTML Content Our Internet Infrastructure at Risk Social Spam Understanding CAPTCHAs and Their Weaknesses Security Questions Folk Models of Home Computer Security Detecting and Defeating Interception Attacks Against SSL

This document defines the syntax and semantics of Do Not Track, anHTTP header-based mechanism that enables users to express preferencesabout third-party web tracking. It also provides a standard for howweb services should comply with such user preferences.

The last three years have seen a dramatic increase in both awareness and exploitation of Web Application Vulnerabilities. 2008 and 2009 saw dozens of high-profile attacks against websites using Cross Site Scripting (XSS) and Cross Site Request Forgery (CSRF) for the purposes of information stealing, website defacement, malware planting, clickjacking, etc. While an ideal solution may be to develop web applications free from any exploitable vulnerabilities, real world security is usually provided in layers. We present content restrictions, and a content restrictions enforcement scheme called Content Security Policy (CSP), which intends to be one such layer. Content restrictions allow site designers or server administrators to specify how content interacts on their web sites-a security mechanism desperately needed by the untamed Web. These content restrictions rules are activated and enforced by supporting web browsers when a policy is provided for a site via HTTP, and we show how a system such as CSP can be effective to lock down sites and provide an early alert system for vulnerabilities on a web site. Our scheme is also easily deployed, which is made evident by our prototype implementation in Firefox and on the Mozilla Add-Ons web site.

We propose an extension to the HTTP protocol that allows specification of domain borders in the form of fences – a service provider is empowered with the ability to specify what exactly they would like to accept as being within their domain. The extension also provides a second asset which is a policy specification or data visa; these visas specify what types of data can be brought into the fence-specified domain from the outside (such as scripts, images, HTML, etc). Together, the fences and visas provide a data “immigration” policy where the authors of a web application can easily specify how data is allowed to enter and exit their application through automated web-based means. These rules can help to prevent unwanted information leak or entry (such as the usual effects of Cross-Site Scripting attacks), as well as similar “loose–origin” vulnerabilities that may not yet be identified. The main benefits realized from our Immigration policy are preventive measures against cross-domain attacks and a relief of burden on web application programmers. Since content restrictions are specified by the web server and enforced by the browser regardless of the data actually served by the website, web application developers need to worry less that their code does the“right thing”with user input. This is especially beneficial as web sites more frequently allow visitors to contribute data in the fashion of the Web 2.0 movement.

The SITDRM Enterprise system [N. Sheppard, R. Safavi-Naini “Protecting Privacy with the MPEG-21 IPMP Framework”. International Workshop on Privacy Enhancing Technologies 2006, pp. 152–171] protects private customer data by allowing customers to provide policies in the form of a machine-readable license. When employees of an organization want to use customers' data, they must be forced to abide by the licences provided. Some sort of hardened terminal must be used to ensure that not only the hardware and software will cooperate, but that the user of the terminal will too. We use the Trusted Computing Group's specifications for a trusted platform upon which to build a data user terminal that can be proved to implement correct license-enforcing behavior. A Trusted Platform Module (TPM) and a TPM-using operating system are all that may be required to construct a verifiably secure terminal.

The vulnerability of home routers has been widely discussed, but there has been significant skepticism in many quarters about the viability of using them to perform damaging attacks. Others have argued that traditional malware prevention technologies will function for routers. In this paper we show how easily and effectively a home router can be repurposed to perform a mid-stream script injection attack. This attack transparently and indiscriminately siphons off many cases of user entered form-data from arbitrary (non-encrypted) Web-sites, including usernames and passwords. Additionally, the attack can take place over a long period of time affecting the user at a large number of sites allowing a userpsilas information to be easily correlated by one attacker. The script injection attack is performed through malware placed on an insecure home router, between the client and server. We implemented the attack on a commonly deployed home router to demonstrate its realizability and potential. Next, we propose and implement efficient countermeasures to discourage or prevent both our attack and other Web targeted script injection attacks. The countermeasures are a form of short-term tamper-prevention based on obfuscation and cryptographic hashing. It takes advantage of the fact that Web scripts are both delivered and interpreted on demand. Rather than preventing the possibility of attack altogether, they simply raise the cost of the attack to make it non-profitable thus removing the incentive to attack in the first place. These countermeasures are robust and practically deployable: they permit caching, are deployed server-side, but push most of the computational effort to the client. Further, the countermeasures do not require the modification of browsers or Internet standards. Further, they do not require cryptographic certificates or frequent expensive cryptographic operations, a stumbling block for the proper deployment of SSL on many Web-servers run by small to medium-sized businesses.

article Share on Mixed nuts: atypical classroom techniques for computer science courses Author: Sid Stamm View Profile Authors Info & Claims XRDS: Crossroads, The ACM Magazine for StudentsVolume 14Issue 4June 2008 pp 22–27https://doi.org/10.1145/1375972.1375978Published:01 June 2008Publication History 1citation284DownloadsMetricsTotal Citations1Total Downloads284Last 12 Months2Last 6 weeks0 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my Alerts New Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

The web has become richer with content, and a host of technologies are in place to improve interactivity – whether between the web browser and web server or between the browser and other desktop applications and network devices. Consequently, there is a greater burden on Web scripting languages to not only support this flexibility, but to do so in a way that does not increase new security risks. While the web browser used to have the responsibility of interpreting web languages and displaying the results, we take the position that the environment with which the user interacts with the web is much more complex and the policies governing these boundaries needs to be better understood (and better enforced). There have been a host of powerful attack concepts that trespass the existing loosely protected boundary, and allow the attacker to infiltrate the user’s home computer and network. These include drive-by pharming, overtaking Google Desktop, and universal cross-site scripting. While these types of attacks are not yet visible in the wild, given their simplicity, we believe it is only a matter of time before they are. In general, we expect this trend to continue and expect to see more powerful attack concepts along similar lines. Overview and Motivation. The Internet, and the World Wide Web in particular, are becoming an increasingly important resource to people in modern society. According to the Pew Internet and American Life project, 42% of adult Americans (43 million people) have a broadband Internet connection at home, and 43% of those people are online for two or more hours per day [4]. Mostly, these people are browsing the web for news, shopping, blogging, researching, or just looking around (surfing), and the vast majority of Internet use is browsing the Web with one of many browsers: Internet Explorer, Firefox, Safari, Opera, etc. Web content is becoming increasingly complex, especially with the “Web 2.0.” movement. Web 2.0 involves the coupling of several concepts: • Increased interactivity through dynamic technologies that heavily use JavaScript and Cascading Style Sheets (such as AJAX), whose popularity makes the Web seem more like a desktop; • User-generated content including not only text-based blogs and wikis, but also more rich content like video; • Richer media capabilities facilitated by browser extensions and plug-ins (e.g., Adobe Flash or PDF viewer). In addition, the Web Browser is now capable of interacting with other desktop applications like Google Desktop or with a user’s home network; these applications or devices often run a web server (though that may not always be apparent to the user). This increased interactivity provides rich functionality, but also poses dangers in that JavaScript (or any other scripting language running in the context of a user’s web browser) can potentially escape past the browser as an emulator and cause serious security concerns. Security Concerns. One interesting security concern along these lines is Drive-by Pharming, a concept co-developed by the authors [5]. In a drive-by pharming attack an attacker can write JavaScript code that when executed in the victim’s browser will mount a cross-site request forgery on the victim’s home broadband router (which hosts a web server) and change its DNS settings. From that point onward, the victim’s DNS

We propose new techniques to combat the problem of click fraud in pay-per-click (PPC) systems. Rather than adopting the common approach of filtering out seemingly fraudulent clicks, we consider instead an affirmative approach that only accepts legitimate clicks, namely those validated through client authentication. Our system supports a new advertising model in which premium validated clicks assume higher value than ordinary clicks of more uncertain authenticity. Click validation in our system relies upon sites sharing evidence of the legitimacy of users (distinguishing them from bots, scripts, or fraudsters). As cross-site user tracking raises privacy concerns among many users, we propose ways to make the process of authentication anonymous. Our premium-click scheme is transparent to users. It requires no client-side changes and imposes minimal overhead on participating Web sites.

In the last few years, obfuscation has been used more and more by spammers to make spam emails bypass filters. The standard method is to use images that look like text, since typical spam filters are unable to parse such messages; this is what is used in so-called "rock phishing". To fight image-based spam, many spam filters use heuristic rules in which emails containing images are flagged, and since not many legit emails are composed mainly of a big image, this aids in detecting image-based spam. The spammers are thus interested in circumventing these methods. Unicode transliteration is a convenient tool for spammers, since it allows a spammer to create a large number of homomorphic clones of the same looking message; since Unicode contains many characters that are unique but appear very similar, spammers can translate a message's characters at random to hide black-listed words in an effort to bypass filters. In order to defend against these unicode-obfuscated spam emails, we developed a prototype tool that can be used with Spam Assassin to block spam obfuscated in this way by mapping polymorphic messages to a common, more homogeneous representation. This representation can then be filtered using traditional methods. We demonstrate the ease with which Unicode polymorphism can be used to circumvent spam filters such as SpamAssassin, and then describe a de-obfuscation technique that can be used to catch messages that have been obfuscated in this fashion.

This paper describes an attack concept termed Drive-by Pharming where an attacker sets up a web page that, when simply viewed by the victim (on a JavaScript-enabled browser), attempts to change the DNS server settings on the victim's home broadband router. As a result, future DNS queries are resolved by a DNS server of the attacker's choice. The attacker can direct the victim's Internet traffic and point the victim to the attacker's own web sites regardless of what domain the victim thinks he is actually going to, potentially leading to the compromise of the victim's credentials. The same attack methodology can be used to make other changes to the router, like replacing its firmware. Routers could then host malicious web pages or engage in click fraud. Since the attack is mounted through viewing a web page, it does not require the attacker to have any physical proximity to the victim nor does it require the explicit download of traditional malicious software. The attack works under the reasonable assumption that the victim has not changed the default management password on their broadband router.

Browser cache and history are intended to be private, yet it's not difficult for malicious Web sites to "sniff" cache entries on visitors' computers and then use that information to more accurately deceive them. The authors' approach neutralizes the threat of URLs being discovered on client computers.

We describe the detrimental effects of browser cache/history sniffing in the context of phishing attacks, and detail an approach that neutralizes the threat by means of URL personalization; we report on an implementation performing such personalization on the fly , and analyze the costs of and security properties of our proposed solution.