今日已更新 133 条资讯 | 累计 37382 条内容
关于我们

标签:#vs

找到 215 篇相关文章

AI 资讯

Why Cursor Writes IDOR Into Your API Routes (CWE-639)

TL;DR AI editors add a login check to your API routes but skip the ownership check, so any logged-in user can read another user's data by changing the ID in the URL (CWE-639, IDOR). It happens because tutorials treat "authenticated" as if it means "authorized," and the AI learned from those tutorials. The fix is one line: scope every lookup to the current user instead of trusting a raw ID from the request. I asked Cursor to build an endpoint that returns an invoice by ID. It gave me clean code. Auth middleware on the route, a database lookup, a JSON response. It ran on the first try. Then I logged in as a different test user and changed the number at the end of the URL. Invoice #1001 belonged to someone else. I got the whole thing back: amount, line items, billing address. No error, no warning. Just another user's private data on my screen. That is IDOR, an Insecure Direct Object Reference, and it is one of the most common holes I find in AI-generated APIs. The frustrating part is that the code looks secure. It even has an auth check. It just checks the wrong thing. The Vulnerable Code The endpoint below is broken because it confirms you are logged in but never confirms the invoice is yours. findById takes the ID straight from the URL and returns whatever it finds. // CWE-639: authenticated, but no ownership check app . get ( ' /api/invoices/:id ' , authenticate , async ( req , res ) => { const invoice = await Invoice . findById ( req . params . id ); res . json ( invoice ); }); The authenticate middleware does its job. It proves the request comes from a real, logged-in user. What it does not prove is that this particular user has any right to invoice :id . Change the ID, get someone else's record. Increment it in a loop and you can walk the entire table. Why This Keeps Happening AI editors confuse authentication with authorization because almost every tutorial they trained on does the same thing. Authentication is "who are you." Authorization is "are you allowed to

2026-07-29 原文 →
AI 资讯

MergeForge: Resolve Git Conflicts in VS Code or Cursor Like in JetBrains

Tired of squinting at VS Code’s stacked merge editor? MergeForge brings a JetBrains-style three-pane conflict resolver to VS Code and Cursor — and pairs it with an AI assistant that actually reads your repository before it suggests a fix. The problem We’ve all been there. You’re halfway through a rebase. Git stops. Twelve files are conflicted. You open one in VS Code… and get that familiar stacked layout: Incoming, Current, and a result pane that somehow still feels like a puzzle with half the pieces missing. If you ever used WebStorm or IntelliJ, you know how good merge tools can feel: Your side on the left Their side on the right The result in the middle Gutter arrows that just… work In VS Code land, that flow never quite arrived. You click Accept Current, Accept Incoming, Accept Both, and hope nothing important got flattened. Word-level diffs? Authorship? A clear “who wrote this chunk?” signal? Often missing when you need them most. And when AI entered the chat, a lot of tools treated conflicts like isolated text blobs: “Here are the <<<<<<< markers. Good luck.” But real merges need context. What was the branch trying to do? What does the surrounding file look like? Who touched this last? Without that, “AI resolve” is just confident guessing. I wanted the JetBrains merge experience — inside VS Code and Cursor — with an assistant that behaves more like a careful teammate than a slot machine. So I built it. The solution: MergeForge MergeForge is an open-source VS Code / Cursor extension that turns conflicted files into a proper three-pane visual merge. Layout: Left Center Right Yours (local) Result (editable, seeded from the merge base) Theirs (incoming) Panes scroll together. Chunks connect with bands. Gutter controls let you accept, ignore, or blend sides without fighting the UI. When you’re done, Apply writes the result and stages it with git. If you prefer Cursor, you’re covered too. The editor works the same; for AI features you plug in your own provider key (

2026-07-23 原文 →
AI 资讯

Contribuir para a comunidade: como destacar isso no seu LinkedIn e currículo

Como eu mostro que estou contribuindo? Posso colocar no meu LinkedIn? E no meu currículo, como faço? Foi a partir dessas dúvidas que eu elaborei esse guia pra você que quer contribuir do seu jeito e mostrar às empresas e às pessoas, de forma clara e estratégica, o que você está fazendo. Vamos lá? 👇 Por que eu deveria mostrar no LinkedIn? LinkedIn é a porta de entrada para o mundo corporativo no Brasil e no mundo. É por meio dele que você mostra "trabalho". E tem mais: não é só experiência remunerada que conta como evidência de que você tem conhecimento e prática, mas também tudo o que você constrói de forma voluntária , seja tirando dúvida de alguém, participando de um projeto open-source ou escrevendo sobre o que aprendeu. Recrutador não lê currículo pensando só em carteira assinada. Lê pensando em capacidade . Você contribui com algo para a comunidade e quer colocar isso no seu perfil. Existem 3 formas que você pode usar, e elas podem ser usadas todas juntas ou só uma. Escolha aquela que fizer mais sentido pro seu perfil ou busque por outras pessoas que você admira dentro da comunidade e veja como elas colocaram no próprio perfil. 1. Seção de Experiência Use como experiência sempre que estiver contribuindo de forma profissional pra uma área que você busca. Se você participa de contribuições no GitHub, seja através de código, documentação ou outra forma, use como experiência. Pessoas que também estão ajudando na moderação ou administração (community managers) podem destacar as responsabilidades ou resultados das suas ações por aqui. Exemplo de como preencher no LinkedIn: Cargo: [cargo que você faz] Open Source Empresa: [Nome do projeto/organização] Tipo de emprego: Meio período (ou Voluntário) Local: Remoto, Brasil Descrição: - Contribuí com [X] pull requests na documentação do projeto [Nome], focando em clareza para novos contribuidores. - Revisei issues abertas e sugeri melhorias de acessibilidade em componentes de UI usando [ferramenta/stack]. - Participei de re

2026-07-23 原文 →
AI 资讯

L3: I built continuous runtime monitoring because certification is point-in-time, attacks are runtime

Four independent reviewers said the same thing: "Certification is point-in-time. Attacks are runtime." — @correctover (CrewAI), @wrencalloway (dev.to), @mads_hansen (dev.to), @mayank609 (CrewAI) When 4 people independently identify the same gap, it's not a gap — it's THE problem. So I built L3. The gap My 8-layer Sentinel pipeline audits skills at import time: L1.5-L1.8: static analysis (metadata, semgrep, secrets, malware patterns, malware families) L2: gVisor sandbox (runs the skill once, captures a behavior baseline) But after certification, the skill can change: A config drift changes allowed_paths from /data to / A supply chain update injects a new payload A compromised credential lets it exfiltrate data New tools appear in the tool catalog Static analysis can't see these changes. L2 captured a snapshot. Neither catches drift. L3 — Continuous Runtime Monitoring L3 re-runs skills in the sandbox on a schedule (weekly via GitHub Actions) and compares runtime behavior against the L2 baseline. If behavior drifts, the skill is flagged. 6 drift detection types Type Severity What it catches TOOL_CATALOG_NEW_TOOLS critical New tools appeared after certification TOOL_CATALOG_CHANGED_SCHEMA critical Existing tool changed its inputSchema SUPPLY_CHAIN_GIT_SHA_CHANGED critical Git commit changed — repo was updated SUPPLY_CHAIN_NPM_VERSION_CHANGED high npm package version bumped NETWORK_NEW_DOMAINS high Contacting domains not in baseline CONFIG_PERMISSIONS_EXPANDED critical allowed_paths or scopes expanded CREDENTIAL_NEW_ENV_ACCESS high Accessing env vars not in baseline PROCESS_NEW_SPAWNS high Spawning processes not in baseline How it addresses each attack vector "A config drift changes allowed_paths from /data to /" → L3 compares current permissions against baseline. If paths expanded → CRITICAL alert → skill re-quarantined. "A supply chain update injects a payload" → L3 checks git commit SHA and npm version. If changed since certification → CRITICAL alert → skill must be r

2026-07-21 原文 →
AI 资讯

Clinejection: How a GitHub Issue Title Compromised an AI Coding Assistant Used by 5M Developers

TL;DR In December 2025, Cline — an AI coding assistant with over 5 million users — gave an AI agent (Claude) write access to triage GitHub issues, including permission to run shell commands. A misconfigured trigger condition let any GitHub user invoke the workflow. What followed was a four-hop supply chain compromise that ended with a malicious npm package silently installing a second AI agent on user machines. I broke down the full chain in video form: Watch the episode Below is the chain, hop by hop. Hop 0: The setup The triage automation was configured with broad tool permissions and a trigger condition open to any GitHub user — not just contributors. That second part is the root cause: it opened the trigger to unauthenticated input. (Exact config values are in the Confirmed Artifacts section below.) Hop 1: Prompt injection via issue title The issue title itself was never sanitized before reaching the model. No first-party source has published the exact injected payload verbatim — GHSA doesn't disclose it — so any reconstruction here is illustrative, not confirmed. What's confirmed is the mechanism: an untrusted string reached the model with tool access already granted. Hop 2: Cache poisoning The injected instruction deployed a tool (multiple independent postmortems — Snyk, Cloud Security Alliance — name it "Cacheract") that flooded the CI cache with over 10GB of junk data, evicting legitimate entries through standard LRU eviction. Hop 3: Nightly workflow inherits the poisoned cache The nightly release workflow restored that poisoned cache around 2 AM UTC and ran inside it — handing over three publish tokens. (Names confirmed across GHSA and multiple independent sources — see below.) Hop 4: Publication cline@2.3.0 went live on npm with a postinstall script that silently installed a second package globally — an AI agent, installed by an AI agent, with no user consent. This line is a direct quote from Cline's own security advisory, not a reconstruction. It's the st

2026-07-19 原文 →
开发者

Sony’s flagship RGB LED TV is incredible

The Sony Bravia 9 II is the most anticipated new TV in years. It's an amazing RGB LED TV. I watched Dungeons & Dragons: Honor Among Thieves on the new Bravia with my son, who has been getting into the roleplaying game but had never seen the movie. The landscapes of Faerûn looked natural and […]

2026-07-18 原文 →
AI 资讯

I Built a VS Code Extension to Upload Code Snippets to PasteDB in One Click 🚀

I created the official PasteDB VS Code extension that lets you upload your current file or selected code directly from Visual Studio Code. It includes secure API key storage, customizable upload settings, recent paste history, automatic language detection, and instant shareable links. In this post, I'll explain how it works, how to install it, and the challenges I faced while building it. More Info View on Marketplace

2026-07-17 原文 →