javascript exploit | Breaking Cybersecurity News | The Hacker News

In an effort to mitigate a large class of potential cross-site scripting issues in Firefox, Mozilla has blocked execution of all inline scripts and potentially dangerous eval-like functions for built-in "about: pages" that are the gateway to sensitive preferences, settings, and statics of the browser. Firefox browser has 45 such internal locally-hosted about pages , some of which are listed below that you might have noticed or used at some point: about:config — panel to modify Firefox preferences and critical settings. about:downloads — your recent downloads done within Firefox. about:memory — shows the memory usage of Firefox. about:newtab — the default new tab page. about:plugins — lists all your plugins as well as other useful information. about:privatebrowsing — open a new private window. about:networking — displays networking information. To be noted, these changes do not affect how websites from the Internet work on the Firefox browser, but going forwar

Shortly after Microsoft announced support for custom JavaScript functions in Excel, someone demonstrated what could possibly go wrong if this feature is abused for malicious purposes. As promised last year at Microsoft's Ignite 2017 conference, the company has now brought custom JavaScript functions to Excel to extend its capabilities for better work with data. Functions are written in JavaScript for Excel spreadsheets currently runs on various platforms, including Windows, macOS, and Excel Online, allowing developers to create their own powerful formulae. But we saw it coming: Security researcher Charles Dardaman leveraged this feature to show how easy it is to embed the infamous in-browser cryptocurrency mining script from CoinHive inside an MS Excel spreadsheet and run it in the background when opened. "In order to run Coinhive in Excel, I followed Microsoft's official documentation and just added my own function," Dardaman said . Here is an official doc

Identities now transcend human boundaries. Within each line of code and every API call lies a non-human identity. These entities act as programmatic access keys, enabling authentication and facilitating interactions among systems and services, which are essential for every API call, database query, or storage account access. As we depend on multi-factor authentication and passwords to safeguard human identities, a pressing question arises: How do we guarantee the security and integrity of these non-human counterparts? How do we authenticate, authorize, and regulate access for entities devoid of life but crucial for the functioning of critical systems? Let's break it down. The challenge Imagine a cloud-native application as a bustling metropolis of tiny neighborhoods known as microservices, all neatly packed into containers. These microservices function akin to diligent worker bees, each diligently performing its designated task, be it processing data, verifying credentials, or

Security researchers have discovered a chip flaw that could nullify hacking protections for millions of devices regardless of their operating system or application running on them, and the worse — the flaw can not be entirely fixed with any mere software update. The vulnerability resides in the way the memory management unit (MMU), a component of many CPUs, works and leads to bypass the Address Space Layout Randomization (ASLR) protection. ASLR is a crucial security defense deployed by all modern operating systems from Windows and Linux to macOS, Android, and the BSDs. In general, ASLR is a memory protection mechanism which randomizes the location where programs run in a device's memory. This, in turn, makes it difficult for attackers to execute malicious payloads in specific spots in memory when exploiting buffer overflows or similar bugs. In short, for attackers, it's like an attempt to burglarize a house blindfolded. But now a group of researchers, known as VUSe